ABOUT  INPUT 


INPUT  provides  planning  information,  analysis, 
and  recommendations  to  managers  and  executives 
in  the  information  processing  industries.  Through 
market  research,  technology  forecasting,  and 
competitive  analysis,  INPUT  supports  client  man- 
agement in  making  informed  decisions.  Contin- 
uing services  are  provided  to  users  and  vendors 
of  computers,  communications,  and  office  pro- 
ducts and  services. 

The  company  carries  out  continuous  and  in-depth 
research.  Working  closely  with  clients  on  impor- 
tant issues,  input's  staff  members  analyze  and 
interpret  the  research  data,  then  develop  recom- 
mendations and  innovative  ideas  to  meet  clients' 


needs.  Clients  receive  reports,  presentations, 
access  to  data  on  which  analyses  are  based,  and 
continuous  consulting. 

Many  of  INPUT'S  professional  staff  members 
have  nearly  20  years'  experience  in  their  areas  of 
specialization.  Most  have  held  senior  management 
positions  in  operations,  marketing,  or  planning. 
This  expertise  enables  INPUT  to  supply  practical 
solutions  to  complex  business  problems. 

Formed  in  1974,  INPUT  has  become  a  leading 
international  planning  services  firm.  Clients  include 
over  100  of  the  world's  largest  and  most  techni- 
cally advanced  companies. 


OFFICES 


AFFILIATES 


Headquarters 

1943  Landings  Drive 
Mountain  View,  CA  94043 
(415)  960-3990 
Telex  171407 

Dallas 

Campbell  Center  1 1 
8150  N.  Central  Expressway 
Dallas,  Texas  75206 
(214)  691-8565 

New  York 

Park  80  Plaza  West- 1 

Saddle  Brook,  New  Jersey  07662 

(201)  368-9471 

United  Kingdom 

INPUT,  Ltd. 

Airwork  House  (4th  Floor) 

35  Piccadilly 

London,  W.I. 

England 

01-439-4442 

Telex  269776 


Australia 

Infocom  Australia 

Highland  Centre,  7-9  Merriwa  St., 

P.O.  Box  110, 

Gordon  N.S.W.  2072 

(02)  498-8199 
Telex  AA  24434 

Italy 

PGP  Sistema  SRL 
20127  Milano 
Via  Soperga  36 
Italy 

Milan  284-2850 
Japan 

Overseas  Data  Service  Company,  Ltd. 

Shugetsu  Building 

No  12  -  7  Kita  Aoyama 

3-Chome  Minato-ku 

Tokyo,  107 

Japan 

(03)  400-7090 
Telex  J26487 


Sweden 

P.O.  Persson  Konsult  AB 
Box  221  14 
Hantverkargatan  7 
104  22  Stockholm 
Sweden 
08-52  07  20 


INPUT 


Planning  Services  for  Management 


SOFTWARE  DEVELOPMENT  PRODUCTIVITY 


Prepared  For: 
COMPUTER  DEVELOPMENT  1_AB0RAT0RIES 


DECEMBER  1982 


K  

1      ■  " 

\  Y-CDL 

CDL 

AUTHOR  1982 

_  Software  development  Producii^ltji 

DATE 
LOANED 

BORROWER'S  NAME 

CAT.   No.   23-108        PRINTED  IN  U.  S.  A. 

SOFTWARE  DEVELOPMENT  PRODUCTIVITY 


CONTENTS 


Page 

I  INTRODUCTION   _  I 

II  EXECUTIVE  SUMMARY  AND  CONCLUSIONS   5 

A.  The  Productivity  Problem  5 

B.  Current  Status  Of  Problem  Definition  And  Solution  7 

C.  Progress  Toward  Problem  Definition  And  Measurement  12 

D.  Attractive  Alternatives  Which  Bypass  The  Problem  14 

E.  Current  Status  Of  Productivity  Methodologies  And 

Tools  15 

F.  Methodologies  And  Tools  Required                     ^  17 

G.  Assessment  Of  IBM  Strategies  19 

III  RESPONDENT  CHARACTERISTICS   23 

A.  Nature  Of  Business/Size  Of  Organization  23 

1 ,  EDP  User  Respondents  23 

2.  Software  Vendor  Respondents  24 

B.  EDP  Organizations  26 

C.  Software  Development  Characteristics  32 

1 .  Systems,  Programs,  Lines  of  Code  Developed/ 

Maintained,  And  Languages  Used  32 

2.  Target  Systems/Software  38 

3.  Hardware/Software  Development  System 

Organization  -  Description  And  Evaluation  40 

4.  Development  Facilities  And  Environments  50 

D.  Conclusions  Concerning  Respondent  Characteristics  55 

IV  SOFTWARE  DEVELOPMENT  PRODUCTIVITY   59 

A.  Introduction  59 

B.  Software  Development  Problems  And  Bottlenecks  65 

1.  Historic  Trends  65 

2.  Prior  INPUT  Research  69 

3.  EDP  Department  Respondents  72 

4.  Software  Vendor  Respondents  80 

5.  Conclusions  About  Software  Development  Productivity  87 

C.  Factors  In  Improving  Software  Development  Productivity  91 

1.  Prior  INPUT  Research  91 

2.  EDP  Department  Responses  96 

D.  Measurement  Processes  And  Methods  100 

E.  Alternatives  For  Systems  Implementation  I  13 

1.  Internal  Development  113 

2.  Package  Purchase  115 


INPUT 

Y-CDL-534 


Page 


3.  End  User  Development  I  17 

4.  Purchase  Of  Services  I  19 

5.  Other  121 
F.      Software  Development  Productivity  Methodologies  And 

Tools  122 

1.  IBM  Analysis  Tools  (BSP  &  BICS)  122 

2.  IBM  Provided  Productivity  Products  127 

3.  Non-IBM  Provided  Methodologies  And  Tools  133 

4.  Methodologies  And  Tools  Required  -144 

V  ASSESSMENT  OF  IBM  STRATEGIES   149 

A.  Reaction  To  ASDC  149 

B.  Preconfigured  Systems  151 

C.  IBM  Information  Network  153 

D.  Effects  Of  Network  Productivity  Products  (MVSPS  And 

VMPS)  156 

E.  IBM  Software  Strategies  For  Low-End  Machines  156 

VI  SOFTWARE  DEVELOPMENT  APPROACH  BY  EDP 

DEPARTMENTS   159 

A.  Introduction  And  Summary  159 

B.  Case  Study  #1  -  Southern  California  Edison  (SCE)  160 

1.  Background  160 

2.  Evaluation  Of  Current  Situation  And  Needs  161 

3.  Tools  And  Techniques  Employed  163 

4.  Assessment  Of  Productivity  Initiatives  163 

C.  Case  Study  #2  -  The  Singer  Company  (Singer)  I  64 

1 .  Background  1 64 

2.  Evaluation  Of  Current  Situation  And  Needs  165 

3.  Tools  And  Techniques  Employed  167 

4.  Assessment  Of  Productivity  Initiatives  168 

D.  Case  Study  #3  -  The  Continental  Insurance  Companies 

(CIO  169 

1.  Background  169 

2.  Evaluation  Of  Current  Situation  And  Needs   ■  169 

3.  Tools  And  Techniques  Employed  170 

4.  Assessment  Of  Productivity  Initiatives  171 

E.  Case  Study  #4  -  McGraw-Hill  Inc.  (MH)  1 72 

1.  Background  172 

2.  Evaluation  Of  Current  Situation  And  Needs  173 

3.  Tools  And  Techniques  Employed  175 

4.  Assessment  Of  Productivity  Initiatives  175 

F.  Case  Study  #5  -  University  Of  North  Carolina 

(UNO  177 

1.  Background  177 

2.  Eviuation  Of  Current  Situation  And  Needs  179 

3.  Tools  And  Techniques  Employed  180 

4.  Assessment  Of  Productivity  Initiatives  181 


ii 


INPU 


G,  Case  Study  #6  -  The  Citizens  And  Southern  Bank 

(C&S)  182 

1 .  Background  1 82 

2.  Evaluation  Of  Current  Situation  And  Needs  183 

3.  Tools  And  Techniques  Employed  184 

4.  Assessment  Of  Productivity  Initiatives  185 

H.  Case  Study  #7  -  Southern  Railway  (NS)  1 86 

1.  Background  186 

2.  Evaluation  Of  Current  Situation  And  Needs  t87 

3.  Tools  And  Techniques  Employed  189 

4.  Assessment  Of  Productivity  Initiatives  190 

VII       SOFTWARE  APPROACH  BY  LEADING  SOFTWARE  VENDORS   1 93 

A.  Summary  And  Analysis  193 

B.  Software  Vendor  Case  Study  //I  -  Mathematica 

Products  Group  (MPG)  195 

1 .  Background  1 95 

2.  Evaluation  Of  Current  Situation  And  Needs  196 

3.  Tools  And  Techniques  Employed  198 

4.  Assessment  Of  Productivity  Initiatives  198 

C.  Software  Vendor  Case  Study  #2  -  Sundance  Systems 

(Sundance)  201 

1 .  Background  20 1 

2.  Evaluation  Of  Current  Situation  And  Needs  201 

3.  Tools  And  Techniques  Employed  203 

4.  Assessment  Of  Productivity  Initiatives  203 

D.  Software  Vendor  Case  Study  #3  -  SAS  Institute,  Inc. 

(SAS)  203 

1 .  Background  203 

2.  Evaluation  Of  Current  Situation  And  Needs  204 

3.  Tools  And  Techniques  Employed  205 

4.  Assessment  Of  Productivity  Initiatives  206 

E.  Software  Vendor  Case  Study  #4  -  Management  Science 

America,  Inc.  (MSA)  207 

1 .  Background  207 

2.  Evaluation  Of  Current  Situation  And  Needs  208 

3.  Tools  And  Techniques  Employed  209 

4.  Assessment  Of  Productivity  Initiatives  210 

F.  Software  Vendor  Case  Study  #5  -  Intel,  Commercial 

Systems  Division  (Intel)  211 

1 .  Background  2 1  I 

2.  Evaluation  Of  Current  Situation  And  Needs  212 

3.  Tools  And  Techniques  Employed  214 

4.  Assessment  Of  Productivity  Initiatives  214 

APPENDIX  A:      LIST  OF  COMPANIES  INTERVIEWED   217 

A.  EDP  User  Respondents  217 

B.  Software  Vendors  2 1 7 

APPENDIX  B:       QUESTIONNAIRE   219 


-  iii  - 


INPUT 


Digitized  by  the  Internet  Archive 

in  2015 


https://archive.org/details/softwaredevelopmunse 


SOFTWARE  DEVELOPMENT  PRODUCTIVITY 


EXHIBITS 

Page 


II       -I  The  Productivity  Pyramid  -  8 

ill       -I  Summary  Of  EDP  Organizations  interviewed                    -  27 

-2  Summary  Of  Vendor  Organizations  Interviewed  30 

-3  EDP  Department  Systems  Development  Languages  34 

-4  Software  Vendor  Systems  Development  Languages  36 

-5  Target  System/Software  41 

-6  Hardware/Software  Development  System  42 

-7  Respondents'  Evaluation  Of  Their  Development  Systems  48 

-8  Development  Environment                              ,  51 


iV       -I       Rankings  Of  System  Software  Attributes  (IBM  Study  - 

1963)  62 
-2      Percent  Of  EDP  Personnel  Budget  Devoted  To  Software 

Maintenance  And  Development  66 

-3  Time  Usage  In  Systems  Development  68 
-4      Most  Important  Factors  Inhibiting  Productivity 

improvement  As  Reported  By  Respondents  70 
-5      Areas  Of  Major  Importance  In  Improving  Software 

Productivity,  As  Reported  By  Respondents  71 
-6      Primary  Problems  And  Bottlenecks  -  EDP  Department 

Respondents  73 
-7      The  Focus  Of  The  Productivity  Problem  EDP  Department 

Respondents  77 
-8      The  Fourth  Generation  "Breakthrough"  (As  Depicted  By 

Vendor  Respondent)  81 

-9      Typical  Project  Workload  Curve  88 

-10      The  Productivity  Pyramid  93 

-I  I      The  Restructured  Productivity  Pyramid  95 

-12      EDP  Departments'  Current  Productivity  Initiatives  97 

-13      The  Measurement  Dilemma:  Pages,  Lines,  Bytes  101 

-14  The  Measurement  Dilemma:  Maintenance  103 
-15      Primary  Measures  Of  Software  Development  Productivity, 

As  Reported  By  EDP  Managers  104 

-16      Productivity  Measurements  Employed  106 

-17      Rating  Of  Software  Implementation  Measurements  108 

-18      Reactions  To  IBM  Productivity  Products  128 

-19      Relative  Costs  Over  System  Life  135 

-20      Applicability  Of  Selected  Tools  136 


-  Iv  - 


INPUT 


Impact  Of  Selected  Tools 

Current  Status  Of  Methodology  Tool  Evaluation  And 
Selection 

Respondents'  Reactions  To  Specific  Methodologies 
(Tools) 

Systems  Development  Approaches  (Cost  And  Size 
Relationships) 


I  INTRODUCTION 


INTRODUCTION 


During  1980,  INPUT  conducted  what  it  believes  to  be  the  most  connprehensive 
research  ever  conducted  in  the  area  of  systems  and  software 
implementation.  This  research  was  sponsored  on  a  multiclient  basis  by  some 
of  the  largest  corporations  in  America  and  consisted  of  the  following: 

In-depth,  on-site  interviews  were  conducted  on  multiple  staff  levels 
(programmer/analyst  through  MIS  Director)  in  approximately  60  firms 
to  determine  their  approaches  to  the  improvement  of  software 
development  and  maintenance. 

An  additional  32  organizations  which  had  taken  specific  actions  were 
interviewed  over  the  telephone. 

A  total  of  1,300  mail  surveys  were  conducted  to  provide  a  statistical 
base  for  evaluating  the  results  of  the  in-depth  interviews. 


Extensive  desk  research  was  conducted  on  published  information. 

When  warranted,  authors  and  experts  in  specific  areas  of  systems 
development  management,  methodology,  and/or  tools  and  aids  were 
interviewed  (either  in  person  or  by  telephone). 

The  analysis  of  these  research  data  resulted  in  a  report  which  presented: 
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The  parameters  of  the  problem  and  the  factors  causing  it. 

An  INPUT  developed  method  and  instrument  to  determine  the  nature 
and  extent  of  the  software  development  problem  within  a  particular 
organization, 

A  description  and  assessment  of  the  various  strategies,  tactics,  tools, 
and  aids  available  to  address  the  problem  and  case  studies  to  illustrate 
effectiveness. 

An  evaluation  of  various  measurement  techniques  and  their  value  in 
preparing  and  controlling  a  software  productivity  improvement  plan. 

Recommendations  to  clients  for  specific  management  strategies  to 
improve  productivity. 

•         With  this  information  base  to  draw  on,  the  specific  research  for  this  study  was 
carefully  targeted  to  obtain  maximum  benefit  from  twelve  on-site  interviews. 

The  seven  users  were  selected  on  the  basis  of  broad  industry  coverage 
and  because  of  the  specific  problems  they  are  attempting  to  solve  (or 
because  people  associated  with  the  companies  had  a  good  perspective 
on  the  problems  most  important  to  the  study).  The  users  interviewed 
were  a  public  utility,  a  state  university,  a  diversified  manufacturing 
company,  a  diversified  insurance  company,  a  major  interstate  bank,  a 
transportation  company  (railroad),  and  a  leading  publishing  and 
information  services  company. 

The  five  vendors  interviewed  were  advocates  and  practitioners  of 
alternative  solutions  to  the  problems  associated  with  conventional,  in- 
house  development  of  applications  systems.  These  vendors  represented 
the  following  approaches  to  solving  the  productivity  dilemma: 
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Fourth  generation  language  (systenns). 
Applications  packages. 

Data  management,  statistical  analysis,  and  information 
(graphics)  display  systems. 

Custom  systems  consulting  and  Implementation  services.  ~~ 

Data  base  processors. 

In  addition,  general  overviews  were  taken  of  three  important  areas  not  specif- 
ically targeted  in  the  research: 

Software  Engineering  Economics  as  presented  by  Barry  W.  Boehm  in  his 
recent  book. 

Information  Engineering  as  advocated  by  James  Martin  and  Clive 
Finklestein. 

Queuing  Networks  as  pursued  by  Dr.  Ralph  L.  Disney  (Virginia  Poly- 
technic Institute)  as  a  possible  approach  to  understanding  the  complex 
communications  and  integration  problems  associated  with  large  com- 
puter/communications applications  systems  implementation. 

If  all  of  our  past  and  current  research  points  to  any  single  conclusion,  it  is 
that  it  is  not  only  wrong,  but  dangerous,  to  view  any  specific  approach, 
methodology,  tool,  aid,  or  vendor  strategy  as  an  isolated  determinant  of 
improved  productivity  in  the  software  implementation  process.  The  general 
framework  of  the  problem  must  be  understood,  and  then  it  will  be  as 
important  to  identify  what  we  really  do  not  know  as  to  act  on  what  we  think 
we  know.  This  report  will  attempt  to  establish  such  a  frame  of  reference. 
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II 


EXECUTIVE  SUMMARY  AND  CONCLUSIONS 


A.       THE  PRODUCTIVITY  PROBLEM 

•  For  nearly  20  years  users  have  expressed  the  simple  request  that  computer 
technology  be  made  easy  to  use. 

•  During  that  time  IBM  developed  increasingly  complex  and  expensive  software 
systems  which  nearly  managed  to  absorb  the  capacities  of  the  faster,  cheaper 
computer  hardware  which  became  available. 

•  These  systems  established  a  complex  man-machine  interface  with  large-scale 
IBM  systems  which,  while  arbitrary  and  unnecessary,  have  become  generally 
accepted  by  several  generations  of  data  processing  personnel. 

•  The  problems  of  "dealing  with  the  system"  have  diverted  many  of  the  most 
talented  technical  personnel  to  systems  programming  where  they  have  been  on 
the  treadmill  of  keeping  up  with  the  latest  hardware/software  developments. 

•  Applications  programmers,  confronted  with  a  constantly  changing  techno- 
logical environment,  have  been  required  (or  have  preferred)  to  concentrate 
more  on  new  hardware/software  technology  than  they  have  on  the  business 
problems  to  be  solved. 
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•  The  lag  between  new  hardware/software  systems  technology  and  practical 
applications  to  business  problems  has  increased  exponentially  since  the  com- 
plexity of  large  systems  has  been  cumulative.  This  has  frustrated  both  execu- 
tive management  and  end  users  for  two  reasons: 

Installed  computer  systems  have  generated  vast  amounts  of  data  which 
defy  human  analysis  and  which  have  complicated  both  business  planning 
and  operations.  Potential  users  of  data  have  discovered  that  "having 
access  to  data"  does  not  solve  problems  -  what  is  needed  is  informa- 
tion. Systems  which  provide  information  have  been  painfully  slow  in 
coming. 

Hardware/software  vendors  have  developed  and  sold  numerous  "solu- 
tions" to  the  problem  of  providing  this  information.  Unfortunately,  the 
"solutions"  have  not  only  consistently  failed  to  solve  the  problem,  they 
have  also  been  extremely  time  consuming  and  expensive  to  imple- 
ment. The  solutions  have  been  eloquently  described  as  "management 
information  systems,"  "data  base  management  systems,"  and  now 
"information  engineering,"  but  over  the  years  they  have  not  produced 
the  promised  results. 

•  The  frustration  of  management  has  been  effectively  diverted  from  the  ven- 
dors, consultants,  and  naive  MIS  directors,  who  really  thought  they  had  the 
answer,  to  the  systems  development  process  in  general.  Why  hasn't  the 
promise  of  technology  been  fulfilled?  The  answer  must  be  in  the  applications 
development  process  itself;  therefore,  the  process  must  be  improved  with 
methodologies,  tools,  and  aids. 

•  The  "solutions"  provided  by  methodologies,  tools,  and  aids  are  then  presented 
to  DP  management  along  with  appropriate  hardware  and  software  tools. 
These  solutions  increase  the  complexity  and  expense  of  hardware/software 
technology  rather  than  solving  the  business  problems. 
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•  As  one  respondent  succinctly  put  it,  "The  productivity  problem  is  very  simple; 
it  exists  because  people  are  working  on  the  wrong  problems.  They  are  concen- 
trating on  technological  problems  (systems)  and  not  on  business  problems." 

•  Layer  upon  layer  of  complexity  has  been  created  in  the  name  of  giving  people 
access  to  information.  Designed  to  make  systems  "easy  to  use,"  the  solutions 
have  become  the  problem,  and  everyone  (vendors,  EDP  departments,  and 
users)  has  become  so  mired  down  in  the  morass  that  most  of  them  cannot 
recognize  the  problem. 

•  Fortunately,  the  economics  of  computer  technology  in  the  form  of  micro- 
processors have  cut  through  the  large  systems'  complexity  to  reveal  the 
truth:  there  is  no  inherent  reason  computer  systems  should  be  either  expen- 
sive or  difficult  to  use.  This  perception  redefines  the  productivity  problem. 

B.       CURRENT  STATUS  OF  PROBLEM  DEFINITION  AND  SOLUTION 

•  When  INPUT  conducted  its  major  productivity  study  two  years  ago,  it  struc- 
tured a  "productivity  pyramid"  to  address  the  development  of  an  improvement 
strategy,  as  shown  in  Exhibit  II-I. 

The  concept  was  that  it  is  necessary  to  proceed  logically  from  a  strong 
foundation  to  build  an  effective  strategy. 

Establishing  commitment  to  quality  is  the  necessary  first  step  in 
building  a  strategy.  In  fact,  the  development  of  a  strategy  in 
itself  could  be  considered  the  preliminary  step  toward  a 
commitment  to  quality. 

End  user  involvement  was  required  in  order  to  be  sure  there 
were  open  communications  and  agreement  on  what  was  being 
done,  and  how  things  worked  together. 
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THE  PRODUCTIVITY  PYRAMID 


-  8  - 


INP 

YCDL 


Broad-based  management  was  required  to  promote  understand- 
ing and  support  of  what  could  and  could  not  be  done  by  DP  and 
also  to  make  DP  management  more  aware  of  business  objec- 
tives. 

After  establishing  the  framework  and  direction  of  the  produc- 
tivity strategy,  a  plan  for  development  of  an  appropriate  and 
effective  personnel  resource  could  be  addressed.  - 

-  .         Providing  the  right  tools  and  aids  was  the  capstone  of  the  pyra- 
mid, to  be  placed  after  the  foundation  was  in  place. 

Our  research  at  that  time  disclosed  that  a  great  deal  of  attention  was 
being  paid  to  the  capstone  and  little  to  the  foundation.  Our  recom- 
mendation was  that  emphasis  should  be  given  to  development  of  a 
strategy  which  would  provide  a  plan  to  build  the  pyramid  from  the 
ground  up. 

It  is  still  our  opinion  that  the  productivity  pyramid  is  structured 
properly,  and  it  is  still  our  recommendation  that  a  productivity  strat- 
egy be  the  first  step  toward  solving  the  problem. 

•  There  have  been  significant  developments  in  productivity  during  the  past  two 
years,  the  most  important  of  which  has  been  the  priority  given  to  user 
involvement. 

Practically  all  respondents  have  some  type  of  plan  to  get  end  users 
involved.  This  involvement  takes  several  forms. 

information  centers  are  being  encouraged  by  IBM,  and  the 
impact  is  already  apparent  since  most  other  companies  have 
either  established  or  plan  to  establish  some  form  of  user 
information  center. 
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Joint  systems  development  teams  are  being  encouraged  and  even 
mandated  by  many  companies. 


Prototyping  is  becoming  the  "in"  approach  to  systems  develop- 
ment (either  by  users  or  by  DP  in  conjunction  with  end  users). 

it  is  our  opinion  that  this  sudden  and  dramatic  shift  toward  end  user 
development  can  be  attributed  to  the  following: 

Personal  computers  are  permitting  end  users  to  do  their  own 
development  with  or  without  DP  sanction. 

IBM,  having  recognized  this  (and  also  having  announced  its 
personal  computer),  wanted  to  get  EDP  departments  involved  in 
the  selection  of  personal  computers  and  in  control  of  the 
applications  being  developed.  (IBM  has  traditionally  been  strong 
with  EDP  departments  and  weak  with  end  users;  the  concept  of 
information  centers  serves  as  a  marketing  bridge  between  IBM 
and  users.) 

There  is  honest  concern  on  the  part  of  some  EDP  departments 
that,  unless  they  establish  some  control  (or  at  least  knowledge) 
of  what  users  are  doing,  they  will  eventually  inherit  a  terrible 
mess. 

While  this  end  user  involvement  with  the  systems  development  process 
must  be  considered  "good,"  it  is  not  being  built  on  a  firm  foundation 
within  a  productivity  strategy.  This  can  conceivably  lead  to  problems 
more  difficult  and  expensive  than  installing  the  wrong  tools. 

•         The  fact  that  many  companies  are  actively  pursuing  information  centers  and 
encouraging  users  to  become  involved  in  the  systems  development  process. 
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even  to  the  degree  of  doing  their  own  development,  is  considered  dangerous 
without  a  productivity  strategy  and  an  underlying  commitment  to  quality. 

The  results  of  such  expedient  tactics  by  the  DP  department  can  be: 

User-developed  systems,  including  prototypes,  will  remain 
installed  and  require  maintenance  and  integration  with  other 
systems.  "~ 

Data  and  information  bases  will  not  be  manageable  and  will 
proliferate  beyond  control. 

Data  processing  personnel  will  become  so  involved  with  the 
development  of  end  user  directed  systems  that  they  will  never 
be  able  to  consider  quality,  much  less  make  a  commitment  to 
it.  Getting  something  done  quickly,  regardless  of  quality  will  be 
the  order  of  the  day. 

The  expense  of  systems  development  will  increase  substantially 
without  really  improving  productivity. 

DP  management  seems  to  feel  compelled  to  its  current  course  by 
several  factors:  ; 

They  are  convinced  things  are  beyond  their  control. 

Vendors  have  convinced  them  that  information  centers  are  the 
panacea. 

They  expect  end  users  to  fall  on  their  faces,  but  involvement 
means  the  user  can't  complain. 
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They  want  to  transfer  development  expense  from  their  budgets 
,         to  those  of  users  where  they  are  more  easily  hidden. 

•  The  general  productivity  problem  still  exists  and  DP  management  still  needs 
to  develop  an  improvement  strategy. 

C.       PROGRESS  TOWARD  PROBLEM  DEFINITION  AND  MEASUREMENT 

•  One  of  the  problems  which  still  exists  is  that  the  specifics  of  the  productivity 
problem  are  not  well  known  or  understood.  Since  the  problem  has  not  been 
defined,  it  obviously  cannot  be  measured,  and  this  makes  it  difficult  to  evalu- 
ate improvement. 

•  Then,  as  the  specific  variables  of  the  problem  are  brought  into  focus,  the  most 
important  ones  turn  out  to  be  the  most  difficult  to  solve.  For  example,  we 
have  determined  that: 

Writing  programs  is  not  the  primary  problem  in  terms  of  time  and 
expense,  but  most  of  the  emphasis  of  tools  and  aids  focus  on  that  phase 
of  the  systems'  life  cycle  (primarily  because  it  lends  itself  to  technical 
solution). 

Essentially,  it  is  a  communications  problem  which  has  been  com- 
pounded by  years  of  mutual  disenchantment  between  DP  personnel  and 
users. 

•  Most  of  the  traditional  weaknesses  in  measurement,  which  were  exposed  in 
the  previous  productivity  study,  still  exist;  however,  some  progress  has  been 
made  in  understanding  it.  Specifically,  a  book  on  Software  Engineering 
Economics  by  Barry  W.  Boehm  has  achieved  the  following: 
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It  has  applied  past  measures  and  rules  of  thumb  in  developing  models 
for  estimating  and  measurement. 

it  has  then  used  the  models  to  develop  a  comprehensive  approach  to 
productivity  measurement  and  improvement. 

It  clearly  identifies  many  critical  variables  and  establishes  ranges  to 
identify  the  importance  of  cost  drives.  ~ 

It  qualifies  carefully  the  use  of  the  models  and  variables  identified. 

•  If  used  intelligently  there  are  many  things  of  value  contained  in  Boehm's  work 
which  would  permit  significant  refinement  of  today's  matrix  which  currently 
consists  primarily  of  meeting  man-month  schedules  and  budgets.  However, 
there  are  those  who  would  prefer  to  seize  on  Boehm's  work  and  state  that  the 
measurement  problem  has  been  solved.  By  claiming  an  engineering  solution,  a 
useful  management  tool  may  be  destroyed. 

•  In  addition,  it  is  possible  that  within  the  next  few  years  work  being  done  on 
queuing  networks  may  find  applications  on  the  more  complex  variables  asso- 
ciated with  software  engineering  (such  as  the  communications  among  project 
team  members  and  users).  Both  Boehm's  work  and  that  being  done  on  queuing 
networks  warrant  careful  analysis  and  consideration. 

•  In  the  meantime,  however,  the  productivity  problems  in  systems  development 
will  remain,  and  controversy  will  continue  about  the  lack  of  responsiveness 
and  low  productivity  of  the  EDP  department.  Fortunately,  there  are  other 
alternatives  for  the  beleaguered  EDP  departments,  and  they  are  becoming 
increasingly  attractive. 
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D. 


ATTRACTIVE  ALTERNATIVES  WHICH  BYPASS  THE  PROBLEM 


•  There  has  been  a  surprising  increase  in  the  use  and  willingness  to  use  pur- 
chased packages  as  an  alternative  to  internal  development.  This  shift  toward 
applications  packages  has  been  identified  both  by  INPUT'S  continued  moni- 
toring of  the  computer  services  industry  and  by  the  research  for  this  study. 

The  purchase  of  applications  software  packages  increased  by  56% 
between  1980  and  1981  against  an  industry  forecast  of  26%. 

Practically  all  respondents  indicate  they  are  either  actively  pursuing 
specific  applications  package  solutions  or  are  willing  to  consider 
them.  Both  the  insurance  and  banking  respondents  indicated  they  are 
evaluating  major  systems  for  purchase. 

One  respondent  went  so  far  as  to  say  that  a  combination  of  purchased 
packages  and  end  user  developments  could  do  away  with  the  need  for 
the  EDP  department  to  develop  systems. 

The  reasons  for  this  increase  in  package  sales  are  as  follows: 

The  increased  pressure  on  EDP  departments  to  produce. 

A  better  understanding  of  the  economics  of  software  develop- 
ment and  maintenance. 

The  improved  quality  of  the  packages  and  the  stability  of  the 
vendors. 

The  perception,  prompted  by  personal  computers  and  small 
business  systems,  that  purchase  of  software  is  the  first  alterna- 
tive and  that  you  only  develop  what  you  can't  buy. 
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IBM's  active  encouragement  of  the  development  of  applications 
for  its  systems  by  independent  software  houses  and  the  recom- 
mendation that  its  customers  consider  such  packages. 


•  The  purchase  of  custom  systems  services,  especially  at  the  low  end  of  the 
line,  is  increasing  because  of  the  nature  of  the  first-time  systems  user  and 
also  for  the  reasons  cited  for  the  purchase  of  packaged  applications 
software.  The  first  time  user: 

Does  not  want  to  hire  a  systems  staff  because  they  are  not  considered 
necessary  in  his  business. 

Could  not  attract  quality  personnel  even  if  he  could  identify  them. 

Thinks  he  knows  exactly  what  he  wants  done  and  that  it  will  never 
change  (require  maintenance);  therefore,  he  can  purchase  what  he 
needs  and  forget  about  it. 

•  Another  alternative  to  in-house  implementation  is  the  shared  development 
expense  of  complex  systems  by  companies  with  similar  requirements.  The 
Insurance  Institute  for  Research  (MR)  is  an  example  of  this.  It  was  funded 
jointly  by  insurance  companies  and  independent  insurance  agents  and  resulted 
in  a  network  which  would  have  been  beyond  the  technical  capacity  of  the 
member  organizations. 


E.       CURRENT  STATUS  OF  PRODUCTIVITY  METHODOLOGIES  AND  TOOLS 


•  There  is  currently  an  impressive  and  growing  array  of  "solutions"  to  the 
productivity  problem  in  the  form  of  methodologies  and  tools.  In  fact,  the 
evaluation  and  implementation  of  these  methodologies  and  tools  are  requiring 
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a  significant  expenditure  of  the  EDP  tecinnical  and  financial  resource  -  fre- 
quently without  measurable  results.  ,  ^: 

•  There  is  no  one  solution,  and  most  respondents  were  somewhat  disenchanted 
with  all  of  the  attention  being  given  to  methodologies  and  tools,  (Although  all 
respondents  see  fit  to  track  developments  in  the  area  in  some  fashion.) 

•  Reaction  to  IBM-provided  analysis  tools  (BSP,  BICS)  and  productivity  products 
was  less  than  enthusiastic.  - 

BSP  and  BICS  were  alternately  considered  too  complicated  or  too 
simplistic  by  respondents,  but  there  was  common  ground  in  the  fact 
that  no  one  found  the  approaches  practical  at  this  time. 

In  general,  IBM  productivity  products  were  found  to  be  less  than  satis- 
factory. There  was  the  general  feeling  that  IBM  only  produces  aids  in 
order  to  solve  their  own  problems  -  deficiencies  in  systems  software, 
competitive  pressure,  marketing  problems,  etc. 

Even  in  cases  where  a  product  has  been  well  received,  as  in  the 
case  of  SPF,  there  was  concern  about  the  expense  of  using  it.  In 
addition,  some  felt  that  IBM  would  find  some  way  to  ruin  the 
product.  (ISPF  was  cited  as  being  a  step  backward.) 

As  stated  by  one  respondent:  "Most  of  the  so-called  produc- 
tivity products  are  really  successor  products  which  attempt  to 
solve  high  problems  IBM  has  created." 

•  The  user  reaction  to  specific  tools  and  methodologies  (pseudo  code,  Jackson 
Methodology,  SADT,  HlPO,  and  Nassi-Schneiderman  Charts)  demonstrated: 

General  familiarity  with  most  of  them,  although  SADT  and  Nassi- 
Schneiderman  Charts  were  not  well  known. 
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Limited  use  by  respondents. 


•  When  asked  about  promising  methodologies  and  tools,  the  responses  varied 
substantially  but  can  be  summarized  as  follows:  ^ 

Yourdon  was  the  only  methodology  mentioned  by  multiple  respondents, 
and  it  was  generally  well  received,  ~ 

Pseudo  code  and  systems  to  facilitate  prototyping  were  generally  well 
regarded  and  considered  promising. 

F.       METHODOLOGIES  AND  TOOLS  REQUIRED 

•  Respondents  were  not  very  specific  about  the  methodology  and  tools  which 
are  required. 

DP  management  responses  reflect  the  confusion  which  results  from  an 
extremely  complex  and  changing  technological  environment. 

Software  vendors  had  a  tendency  to  believe  their  particular  solution 
could  be  extended  to  solve  most  productivity  problems. 

•  It  was  possible,  however,  to  isolate  some  general  requirements  based  on  the 
responses  and  an  analysis  of  the  problem  areas  the  respondents  identified. 

There  is  a  need  for  a  "fifth  generation  language"  which  would  encom- 
pass the  many  languages  and  methodologies  used  today.  This  language 
would  span  the  systems  development  life  cycle  and  improve  communi- 
cations between  users  and  analysts/programmers. 
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There  is  also  a  requirement  for  education  and  training  which  would 
improve  communications  on  a  broader  basis  than  that  of  the  fifth 
generation  language.  It  is  concluded  that  effective  training  tools  for 
executives,  EDP  management,  programmers/analysts,  and  end  users 
would  probably  improve  productivity  more  than  any  specific  software 
development  aids. 

The  need  for  performance  improvement  of  the  basic  IBM  operating 
systems  environment  is  implicit  in  the  concern  and  rejection  of  produc- 
tivity products  because  of  their  excessive  use  of  systems  resources. 
Major  technological  advances  (such  as  relational  data  base  system)  with 
potential  for  productivity  improvement  have  failed  in  the  complex, 
large-scale  system  environment  because  of  environmental  performance 
problems.  Tools  which  correct  (or  bypass)  this  environment  are  needed; 
an  example  would  be  distributed  architecture  through  data  base 
machines. 

At  the  present  time,  there  is  also  a  need  for  tools  to  analyze  the 
methodologies  and  tools  (just  as  tools  are  required  to  build  tools). 
Specifically,  the  following  would  be  helpful: 

A  detailed  data  base  of  available  methodologies  and  tools. 

.  Analysis  of  their  applicability  and  productivity  improvement 
characteristics  (this  implies  improved  measurement  technology 
as  mentioned  previously). 

Instruction  and  training  in  their  use  (including  the  opportunity  to 
try  various  approaches  on  an  economic  basis). 

On  a  broad  scale,  INPUT  sees  the  need  for  an  integrated  set  of  tools 
which  would  permit  broad  data  and  information  analysis  approaches 
such  as  those  advocated  by  IBM's  BSP  and  by  the  "information  engi- 
neering" approaches  espoused  by  Finkelstein  and  Martin. 
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G. 


ASSESSMENT  OF  IBM  STRATEGIES 


•  The  reaction  to  ASDC  was  quite  vague  because  most  respondents  could  not 
identify  the  conference.  However,  there  was  considerable  interest  in  IBM's 
applications  systems  development  strategy.  Generally,  the  reaction  was: 

IBM  will  go  to  any  lengths  to  get  their  hardware  installed,  and  this 
includes  encouraging  independent  software  developers  to  provide 
software  and,  more  important,  to  recommend  that  their  users  seek  such 
sources. 

However,  most  respondents  felt  IBM  would  prefer  to  maintain  account 
control  and  obviously  would  like  to  obtain  the  revenue  from  applica- 
tions software. 

The  question  then  becomes  whether  or  not  IBM  can  regain  (or  establish) 
a  position  as  a  sole-source  systems  supplier.  The  answers  to  that  were 
mixed: 

Many  respondents  felt  IBM  would  acquire  the  products  from  the 
independent  systems  houses  and  regain  control. 

Others,  primarily  the  software  developers,  felt  IBM  would  never 
be  successful  (dominant)  in  the  applications  software  market. 

•  The  consensus  was  that  IBM's  primary  objective  in  preconfiguring  the  4321  and 
4331-11  systems  was  to  simplify  installation  for  low-end  users.  The  fear  of 
IBM's  returning  to  "bundled  systems,"  as  expressed  by  ADAPSO,  was  not 
prevalent  among  the  respondents. 

There  was  a  rough  general  consensus  that  IBM  would  pursue  more 
preconf igured  systems,  and  the  belief  was  even  expressed  that  hard- 
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ware/software-designed  systems  such  as  System/38  were  the  wave  of 
the  future. 

Since  the  research  for  this  study  was  conducted,  IBM  has  announced  the 
4341-9  and  -12  and  has  extended  SSX/VSE  to  the  4341  processors  as 
well  as  to  the  3601,  3602,  and  4701  controllers. 

There  does  not  seem  to  be  any  question  that  IBM  intends  to  pursue 
their  prepackaged  concept.  However,  they  are  emphasizing  that  the 
components  of  the  operating  system  are  available  on  an  "unbundled" 
basis. 

•  Most  respondents  were  less  than  excited  about  the  IBM  Information  Network. 
Once  again,  they  viewed  it  as  providing  a  means  to  assist  in  the  in-house 
installation  of  IBM  hardware  and  software  products.  There  are,  however, 
more  significant  ramifications  of  the  Information  Network  Service. 

Some  respondents  were  thoughtful  enough  to  perceive  the  following: 

IBM  is  a  competitor  in  the  electronic  information  (publishing) 
business. 

There  is  potential  for  providing  the  interconnection  of  various 
users  and  advanced  network  management  services. 

Since  the  research  for  this  report  was  completed,  it  has  been  an- 
nounced that  the  IBM  Information  Network  has  been  awarded  a  con- 
tract to  run  the  insurance  network  developed  by  the  Insurance  Institute 
for  Research  (MR)  mentioned  previously.  This  has  substantial  subsid- 
iary potential  for  IBM  in  terms  of  hardware,  software,  and  services 
sales  to  the  companies  and  agents  who  will  be  using  the  network. 
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It  is  also  INPUT'S  conclusion  that  the  type  of  electronic  information 
services  projected  for  the  network  will  specifically  address  certain  of 
the  productivity  improvement  requirements  outlined  earlier  in  this 
summary. 

IBM  already  has  an  information  base  on  its  own  products  and 
services.  It  is  probable  that  this  will  be  extended  to  incorporate 
those  of  competitors.  (This  was  the  conclusion  of  several  of 
the  respondents.) 

The  potential  for  education  courses  was  also  cited  by  respon- 
dents. 

Proprietary  productivity  improvement  aids  such  as  fourth  (and 
fifth)  generation  languages  are  also  a  good  possibility  and  were 
specifically  mentioned  by  one  respondent. 

it  is  possible  to  summarize  the  future  of  the  IBM  network  as  being 
directed  primarily  at  providing  services  to  improve  productivity  in  the 
systems  development  process.  Whether  that  improvement  is  reflected 
in  trying  new  productivity  tools,  educating  management,  or  managing  a 
client's  network,  the  direction  is  toward  advancing  computer/communi- 
cations information  systems.  The  current  network  tools  such  as  MVSPS 
and  VMPS  are  only  harbingers,  and  the  fact  that  they  were  not  enthu- 
siastically received  by  respondents  (and  they  were  not)  does  not  detract 
from  the  future  success  of  the  network. 

•         IBM's  strategy  for  small-scale  systems  (or  all  systems  for  that  matter)  is 
summarized  as  follows: 

Dominate  the  hardware  market  by  getting  systems  installed  rapidly. 
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Encourage  applications  software  development  for  IBM  systems  not  only 
to  promote  hardware  installation,  but  to  familiarize  software  devel- 
opers with  IBM  systems  and  to  concentrate  a  valuable  resource 
(systems  development  talent)  on  IBM  systems. 

Since  IBM  systems  software  and  productivity  aids  are  the  user  inter- 
face to  IBM  systems,  they  maintain  as  much  control  as  possible  in  that 
area  by  any  means  necessary  (including  bundled  IBM  hardware/firm- 
ware/software). 

The  low-end  systems  of  today  will  form  the  central  office  systems  of 
the  future;  therefore,  they  will  be  marketed  with  that  in  mind  (^3XX 
and  System/38  being  alternatives  depending  upon  particular  circum- 
stances). 

As  conventional  data  processing  and  office  systems  merge  in  the  1980s, 
be  prepared  to  provide  total  electronic  systems  for  the  office  -  data 
processing,  word  processing,  electronic  filing,  systems  software,  local 
area  networks,  and  the  total  electronic  office  operation  (applications). 
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RESPONDENT  CHARACTERISTICS 


Ill       RESPONDENT  CHARACTERISTICS 


A.       NATURE  OF  BUSINESS/SIZE  OF  ORGANIZATION 

I.       EDP  USER  RESPONDENTS 

•         Seven  companies  from  diverse  industries  were  interviewed  on-site.  These 
companies  were: 

Southern  California  Edison  (SCE),  a  public  utility  with  revenue  of  $5.5 
billion. 

The  Singer  Company  (Singer),  a  diversified  manufacturing  and  retailing 
organization  with  revenue  of  $3.8  billion. 

The  Continental  Insurance  Companies  (CiC),  a  diversified  insurance 
enterprise  with  revenue  of  $3.2  billion. 

McGraw-Hill,  Inc.  (MH),  a  publishing  and  information  services  company 
with  revenue  of  $  1 .1  billion. 

The  Citizens  and  Southern  Bank  (C&S),  a  commercial  bank  with  assets 
of  $4.9  billion. 
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University  of  North  Carolina  at  Chapel  Hill  (UNC),  a  major  state 


university  with  an  enrollment  of  over  21,000  students. 

Norfolk  Southern  (NS),  a  newly  consolidated  railway  system  (formerly 
Norfolk  and  Western,  and  Southern  Railway  System)  with  combined 
revenue  of  over  $2  billion. 

•  User  respondents  were  selected:  ~~ 

To  obtain  broad  industrial  representation. 

Because  they  have  adopted  particular  approaches  to  systems  develop- 
ment management. 

•   Because  they  have  particular  problems. 

Because  they  have  particular  personnel  with  good  qualifications  to 
address  productivity  problems. 

The  interview  list  is  contained  in  Appendix  A,  and  the  reasons  for 
selection  will  be  explained  as  appropriate  in  the  case  studies  contained 
in  Chapter  VI.  A  copy  of  the  questionnaire  used  is  contoined  in 
Appendix  B. 

2.       SOFTWARE  VENDOR  RESPONDENTS 

•  Five  software  vendors  were  Interviewed  on-site.  These  particular  vendors 
were  selected  primarily  because  they  offer  different  approaches  to  ease  the 
productivity  problem  associated  with  conventional,  in-house  development  of 
applications  software.  The  specific  companies  or  organizational  entities 
Interviewed  were  as  follows: 

The  Mathematica  Products  Group  (MPG)  of  Mathematica  has  two 
primary  products:   RAMIS  II,  a  fourth  generation  software  system,  and 
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a  teleprocessing  monitor.  MPG  has  revenue  of  approximately  $18 
million. 

SAS  Institute,  Inc.  (SAS)  is  the  developer  of  statistical  analyses  and 
graphics  display  software  packages.  The  company  had  grown  from  100 
employees  at  the  beginning  of  1982  to  175  at  the  time  of  interview,  and 
the  current  rate  of  growth  was  stated  to  be  five  new  employees  per 
week.  The  interviewee  was  reluctant  to  give  revenue  figures  because 
any  he  could  provide  would  be  "misleading"  because  the  company  is  on 
such  a  fast  growth  track. 

Management  Science  America,  Inc.  (MSA)  calls  itself  "The  Software 
Company"  and  has  a  wide  assortment  of  financial  reporting,  cash 
management,  payroll,  personnel,  and  manufacturing  systems  for  sale. 
More  recently,  it  has  acquired  Peachtree  Software  which  provides 
accounting  and  word  processing  software  for  microprocessors.  Its 
revenue  is  approximately  $100  million. 

Sundance  Systems  is  a  custom  consulting  and  systems  development 
company  which  specializes  in  the  low  end  of  the  IBM  line  with  special 
emphasis  on  System/38.  Revenue  is  approximately  $500,000. 

Intel  Systems  Corporation  (ISC)  is  part  of  the  Systems  Group  (CSD)  of 
the  Intel  Corporation.  ISC  represents  the  acquisition  of  MRI  which  was 
the  developer  of  System  2000  (a  data  base  management  system).  More 
important,  ISC  led  the  development  of  the  Intel  Data  Base  Processor 
(iDBP  86/440)  which  is  just  being  brought  to  market  by  CSD.  Revenue 
from  ISC  alone  is  approximately  $16  million. 

•         The  vendors  selected  offer  various  alternatives  to  improving  productivity  in 
the  systems  development  process: 
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Mathematica  (MPG)  offers  a  fourth  generation  language  in  which  the 
client  can  implement  applications  more  easily. 

SAS  takes  particular  functions  (statistical  analysis  and  graphics  display) 
which  are  common  to  a  broad  spectrum  of  applications  systems  and 
provides  packaged  software. 

MSA  provides  software  packages  to  support  a  wide  variety  of  commer- 
.  .  cial  systems. 

Sundance  provides  custom  consulting  and  systems  development  services 
which  can  be  used  to  replace  or  supplement  in-house  systems  develop- 
ment activities. 

-  Intel  (ISC)  provides  a  hardware/software  data  base  solution  which 
facilitates  the  implementation  of  data  base  management  systems 
(including  relational). 

•  The  interview  list  is  contained  in  Appendix  A,  and  a  copy  of  the  questionnaire 
is  in  Appendix  B.  Additional  supporting  information  on  the  vendors  selected  is 
contained  as  appropriate  in  the  case  studies  contained  in  Chapter  VII. 

B.       EDP  ORGANIZATIONS 

•  The  user  EDP  organizations  interviewed  are  summarized  in  Exhibit  III-I.  The 
organizational  level  of  the  interviewee  is  designated  by  giving  his  title  and 
describing  his  reporting  structures  (general  organization  charts  are  outlined  in 
the  interview  guides  in  Appendix  A).  The  number  of  EDP  personnel  and  the 
budget  dollars  are  for  the  entire  EDP  organization  (including  operational 
personnel)  unless  otherwise  specified. 
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The  data  processing  budget  per  EDP  employee  ranged  from  $28,600  per 
employee  at  the  University  of  North  Carolina  to  $76,400  at  Southern 
California  Edison.  Considering  various  accounting  practices  applied  to 
EDP  organizations  and  variation  in  physical  facilities,  even  this  wide 
range  can  be  rationalized  to  a  certain  degree. 

SCE's  budget  of  $76,400  per  employee  includes  the  expense  of 
depreciation  on  the  installed  computer/communications  net- 
works, and  it  is  also  probable  that  other  accounting  practices 
encourage  this  high  investment  in  order  to  support  rate  struc- 
tures. 

Singer  is  currently  decentralizing  its  data  processing  facilities 
to  its  divisions  after  a  number  of  years  in  a  highly  decentralized 
environment.  No  reliable  figures  on  either  personnel  or  hard- 
ware budgets  were  available  from  the  interviewee,  and  it  is 
doubtful  that  such  figures  are  available  within  the  enterprise. 
This  situation  will  be  discussed  in  detail  in  the  Singer  case  study. 

CIC  has  the  largest  total  budget  ($55  million)  and  the  largest 
number  of  EDP  employees  (1,180)  among  the  respondent  com- 
panies. The  EDP  budget  of  $46,600  per  employee  is  the  lowest 
other  than  UNC.  It  is  probable  that  the  primary  reason  for  this 
is  that  CIC  has  withdrawn  from  the  computer  services  business 
during  the  last  six  months.  The  shift  from  a  profit  center  to  a 
cost  center  has  probably  been  accompanied  by  some  subsidy  to 
internal  users  to  compensate  for  the  sudden  withdrawal  of 
outside  income  to  support  the  installed  computer/communica- 
tions network. 

McGraw-Hill's  EDP  budget  does  not  include  the  hardware  or 
systems  support  for  its  information  services  operation  such  as 
Data  Resources,  Inc.     It  represents  the  internal  systems  to 


-28- 


INP 


support  the  corporation.  The  average  expenditure  of  $64,700 
per  employee  is  second  highest  to  SCE,  and  can  be  explained  by 
a  substantial  investment  in  the  computer/communications 
network  and  in  outstanding  physical  facilities.  Since  McGraw- 
Hill  is  in  the  information  business,  it  has  a  "show  case"  informa- 
tion systems  center. 

C&S  and  Southern  Railway  (the  portion  of  NS  analyzed)  are 
located  across  the  street  from  each  other  in  Atlanta,  Georgia, 
and  their  EDP  budgets  per  EDP  employee  are  remarkably  similar 
-  $56,000  for  C&S  and  $56,700  for  Southern. 

UNO's  lowest  budget  of  $28,600  per  EDP  employee  is  attribut- 
able to  geographic  concentration,  low-cost  physical  facilities, 
and  a  salary  scale  which  seemed  to  be  of  primary  concern  to 
EDP  management. 

•  The  vendors  interviewed  are  summarized  in  Exhibit  III-2.  Detailed  informa- 
tion concerning  organizational  relationships  are  contained  in  the  interview 
guides  included  in  Appendix  A.  For  a  number  of  reasons,  development  budget 
figures  were  difficult  to  obtain  for  the  vendors  (much  of  this  had  to  do  with 
customer  support  activities).  Therefore,  the  number  of  personnel  associated 
directly  with  product  development  (including  operations)  has  been  estimated 
and  sales  figures  have  been  given  rather  than  budget  numbers. 

As  would  be  expected,  the  sales  per  development  employee  also  varied 
substantially,  ranging  from  $100,000  for  Sundance  to  $200,000  for 
MSA.  While  it  was  necessary  to  make  estimates  on  both  the  number  of 
development  personnel  and  sales  figures  as  indicated  in  Exhibit  III-2,  it 
is  possible  to  do  at  least  a  rough  analysis  of  the  ratios. 

MPG  and  ISC  both  have  one  major  software  product  (RAM IS  I! 
and  System/2000)  to  support,  and  both  have  approximately  the 
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same  sales  per  development  employee  -  $158,000  for  MPG  and 
$146,000  for  ISC.  They  also  are  very  close  in  terms  of  sales. 

SAS  is  a  very  fast  growing  small  firm  which  has  increased  from 
less  than  100  employees  a  year  ago  to  over  175  at  the  present 
time  and  was  growing  at  a  rate  of  five  employees  per  week  when 
interviewed.  Sales  are  increasing  faster  than  they  can  recruit 
technical  employees.  The  estimated  sales  of  $180,000  per 
employee  is  "reasonable,"  but  it  should  be  pointed  out  that 
INPUT  was  required  to  estimate  both  the  revenue  figure  as  well 
as  the  operational  personnel  to  support  the  development  efforts 
(professional  systems  development  personnel  for  SAS  was  re- 
ported to  be  41  at  the  time  of  interview). 

MSA  is  by  far  the  largest  and  best  established  firm  interviewed 
and  has  the  highest  productivity  in  terms  of  sales  per  develop- 
ment employee  -  estimated  to  be  approximately  $200,000  per 
employee.  The  $100  million  revenue  figure  is  for  1982  and  was 
obtained  during  the  course  of  the  interview.  The  number  of 
personnel  devoted  to  systems  development,  maintenance,  and 
operations  also  had  to  be  estimated. 

At  the  other  extreme,  the  $100,000  of  revenue  per  development 
employee  is  not  surprising  considering  the  custom  nature  of 
Sundance's  business.  (The  economics  of  custom  systems  imple- 
mentation from  an  outside  services  company  as  an  alternative  to 
in-house  systems  development  will  be  explored  in  Chapter  iV 
which  analyzes  software  development  productivity.) 
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C.       SOFTWARE  DEVELOPMENT  CHARACTERISTICS 


I.  SYSTEMS,  PROGRAMS,  LINES  OF  CODE  DEVELOPED/MAINTAINED,  AND 
LANGUAGES  USED 

•  From  previous  INPUT  research,  we  are  aware  that  no  consistent  definitions 
are  available  for  "system,"  "program,"  or  "line  of  code."  For  that  reason,  we 
have  adopted  definitions  as  follows: 

System  refers  to  a  user  generated  application  which  consists  of  an 
organized  collection  of  procedures  united  by  regulated  interaction  to 
accomplish  a  specific  set  of  functions. 

Program  refers  to  a  series  of  instructions  or  statements,  in  a  form 
acceptable  to  a  computer,  prepared  to  achieve  a  certain  result  (for 
example,  to  perform  a  certain  function  in  a  system). 

-      "  Line  of  code  is  defined  as  everything  between  statement  delimiters 
excluding  re-used  code,  comments,  and  compiler  directions. 

•  Even  when  interviewees  were  supplied  with  these  definitions,  they  could 
respond  only  roughly  to  the  total  systems  development  and  maintenance 
responsibility  of  their  organizations.  This  is  probably  due  to  the  level  of  the 
people  interviewed  and  the  confusion  concerning  not  only  the  terms  defined 
above  but  also  concerning  what  constitutes  development,  enhancement,  and 
maintenance. 

•  The  respondents  were  more  comfortable  providing  information  concerning  the 
languages  being  used  for  development  and  maintenance.  This  is  probably 
because  language  standards  have  been  in  effect  for  a  number  of  years.  The 
general  tone  of  the  maintenance  responses  was  less  certain,  probably  indicat- 
ing that  the  number  of  old  programs  around  is  unclear,  and  the  relative  effort 
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to  maintain  old  programs  in  seldom-used  languages  may  be  substantially 
greater  than  the  actual  percent  would  indicate. 

•  Generally  speaking,  the  user  EDP  departments  can  be  characterized  as  having 
one  hundred  or  fewer  systems,  thousands  of  programs,  and  millions  of  lines  of 
code,  and  being  written  primarily  in  COBOL,  as  shown  in  Exhibit  lli-3.  The 
quality  of  the  responses  by  company  can  be  characterized  as  follows: 

Southern  California  Edison  seemed  quite  confident  of  the  number  of 
systems  but  did  not  know  the  number  of  programs.  The  estimate  of 
lines  of  code  was  qualified  as  strictly  a  guess,  and  since  only  SCE  would 
even  guess,  it  seems  clear  that  lines  of  code  are  not  being  measured  by 
respondent  EDP  departments.  The  language  usage  pertains  to  current 
systems  development  and  maintenance  and  does  not  yet  reflect  the 
establishment  of  an  information  center  which  may  result  in  user 
(and/or  information  center)  developed  prototypes  becoming  production 
systems. 

Singer  saw  fit  to  distinguish  between  major  and  minor  systems.  Major 
systems  were  distinguished  as  being  either  interactive  systems  or  those 
taking  substantial  computer  resources  as  indicated  by  monthly  billings 
exceeding  $5,000.  (The  reply  does  not  include  the  engineering  work 
being  done  on  government  contracts  by  Kearfott  since  their  systems 
are  not  being  developed  to  run  in  production  at  the  data  center.) 
Singer  obviously  has  not  seen  fit  to  establish  an  enforceable  COBOL 
standard  for  development  of  commercial  systems  since  20%  of  develop- 
ment is  being  done  in  other  languages.  In  addition,  the  Director  of 
Operations  is  currently  beginning  to  make  ADRS  available  to  end  users 
so  they  can  do  their  own  development. 

The  Continental  Insurance  Companies  currently  have  Computer  Auto- 
mation minicomputers  installed  for  which  they  are  still  developing  new 
systems.  This  accounts  for  the  5%  of  the  development  work  which  is 
not  being  done  in  COBOL. 
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EXHIBIT  III-3 

EDP  DEPARTMENT  SYSTEMS  DEVELOPMENT  LANGUAGES 


NUMBER 

DEVELOPMENT 

MAINTENANCE 
LANGUAGE 

LINES 

LANGUAGE 

COMPANY 

SYSTEMS 

PROGRAMS 

OF  CODE 

(percent) 

(percent) 

SCE 

130 

15  Million 

COBOL  85% 
Fortran  13 
PL/1  2 

Same 

Singer 

25  Major 

800-1, 000 

— 

COBOL  80% 

(Commercial) 

35  Minor 

1 

Mark  III  ^ 
Basic  >20 
RPG  ) 

About  the 
Same 

CIC 

inn 

COBOL  95% 

Cvbol  ) 
^  5 
Assembler ) 

About  the 
Same 

MH 

1  n  nnn 

COBOL  100% 
f  Production 
Programs) 

COBOL  95% 
EasvCoder  5?; 

CSS 

12  Major 
25  Minor 

COBOL  100% 

COBOL  >90% 
Assembler  <10% 

UNC 

3,000 

COBOL  99% 

PL/1 

Assembler  \ 

Same 

NS 

9,500 

COBOL  100% 

Same 
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McGraw-Hill  has  a  COBOL  standard  for  all  new  development  of 
production  programs.  However,  5%  of  their  production  programs  still 
must  be  maintained  in  Easycodes. 

Up  until  three  and  one-holf  years  ago,  Citizens  and  Southern  had  most 
of  their  production  systems  written  in  Assembler.  These  systems  have 
recently  been  converted  to  COBOL,  so  the  number  of  systems  is  prob- 
ably quite  accurate,  and  so  is  the  fact  that  less  than  10%  of  the 
systems  being  maintained  remain  in  COBOL. 

The  University  of  North  Carolina  is  currently  undergoing  conversion 
from  Univac  to  IBM  hardware.  This  conversion  is  being  facilitated  by 
having  had  a  COBOL  standard,  it  is  somewhat  ironic  that  Univac  and 
RCA  (the  equipment  being  replaced  goes  back  to  Spectra  70  days) 
promoted  COBOL  among  IBM  customers  so  that  conversion  to  competi- 
tive hardware  would  be  simplified  and  that  this  strategy  is  now  working 
in  reverse. 

Southern  Railway  established  a  COBOL  standard  early  in  the  1960s,  and 
all  9,500  of  its  programs  are  written  in  that  language.  Jack  Jones,  the 
Norfolk-Southern  Vice  President  of  MIS,  was  a  leading  figure  in  estab- 
lishing COBOL  as  G  language  while  he  was  with  the  United  States  Air 
Force,  and  he  established  and  enforced  the  standard  upon  joining 
Southern  in  1963. 

•  The  software  vendors  were  not  much  better  than  the  user  EDP  departments  in 
having  quantitative  measurements  readily  available  below  the  system  (prod- 
uct) level.  It  appears  obvious  that  software  houses  do  not  emphasize  lines  of 
code  in  terms  of  either  project  estimating  or  in  measuring  productivity. 
However,  they  were  more  likely  to  have  opinions  on  the  subject,  and  the 
development  languages  used  presented  some  interesting  patterns,  as  shown  in 
Exhibit  III-4. 
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EXHIBIT  III-4 


SOFTWARE  VENDOR  SYSTEMS  DEVELOPMENT  LANGUAGES 


NUMBER 

DEVELOPMENT 
LANGUAGE 
( percent) 

MAINTENANCE 

LANGUAGE 
-  (percent) 

COMPANY 

SYSTEMS 

PROGRAMS 

LINES 
OF  CODE 

MPG 

Ramis  II 
(Administrative) 
Assembler 
(Ramis  II) 

Same 
Same 

C  A  C 

• 

1, 000, 000 

Dl    /  1  cr\o 
rL  /  1  50^ 

Assembler  50 
Packages 

Same  Except 
Small  Amount 
Fortran  1% 

MSA 

COBOL  95% 
AssemDier  d 
Systems  &  DBMS 
COBOL  30% 
Assembler  70 

Same 

Sundance 

25 

(12  Months, 
Custom) 

250 

NA 

COBOL  90% 
Basic  5 
RPG  5 
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Mathematica  uses  RAMIS  II  for  all  of  its  internal  administrative  pro- 
cessing except  Corporate  Receivables  where  they  have  the  MSA  pack- 
age installed.  RAMIS  11  itself  is  written  in  Assembler. 

SAS  estimates  that  they  currently  have  approximately  one  million  lines 
of  code  in  SAS,  SAS/Graph  and  the  underlying  operating  systems,  and 
data  base  interfaces.  '  "~ 

Nine  systems  people  develop  and  maintain  statistical  proce- 
dures, four  are  required  for  the  graphics  display  package 
(SAS/Graph),  four  are  required  for  the  CMS  version  of  SAS,  and 
fourteen  are  needed  for  the  other  IBM  operating  systems  and 
data  base  interfaces. 

The  respondent  estimated  that  SAS/Graph  had  more  lines  of 
code  than  any  of  the  others,  and  he  used  this  as  an  example  of 
why  "man-months  in  a  product"  is  a  more  meaningful  measure  of 
complexity  and,  therefore,  effort  required  (both  development 
and  maintenance). 

The  SAS  experience  clearly  indicates  that  DBMS  and  operating 
systems  interfaces  require  more  continuing  effort  than  product 
maintenance  and  that  subsystem  size  is  not  a  good  predictor  of 
maintenance  required.  The  statistical  procedures  portion  of  SAS 
requires  more  than  twice  as  many  personnel  as  the  graphics 
portion,  which  has  the  most  lines  of  code. 

SAS  is  written  in  a  combination  of  PL/ 1  and  assembler  with  only 
a  negligible  amount  of  FORTRAN  remaining  to  be  maintained. 
(The  selection  of  PL/ 1  as  a  development  language  is  currently 
presenting  a  problem  as  they  consider  implementation  on  minis 
and  micros.) 
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MSA's  applications  packages  are  written  primarily  in  COBOL  (95%) 
except  where  interfacing  with  hardware  vendor  software  is  required  or 
performance  considerations  dictate  use  of  assembly  language.  They 
are  currently  implementing  an  in-house  development  system  which  is 
being  written  primarily  in  assembly  language  (COBOL  30%,  Assembler 
70%),  but  this  will  not  significantly  impact  the  product  language  rates 
since  it  will  produce  COBOL  programs.  (This  system  will  be  described 
later.) 

Over  the  last  12  months,  Sundance  has  produced  25  custom  systems 
consisting  of  approximately  250  programs.  These  systems  have  been 
developed  primarily  in  COBOL  (90%). 

TARGET  SYSTEMS/SOFTWARE 

Except  for  the  University  of  North  Carolina,  all  of  the  EDP  departments 
interviewed  had  at  least  an  IBM  3033  installed.  Since  UNC  is  just  in  the 
process  of  converting,  IBM  would  probably  like  to  see  them  outgrow  their  4341 
II  and  graduate  to  a  30XX  system  at  some  point  in  the  future.  All  of  the 
companies  interviewed  are  running  MVS,  and  the  success  of  IBM  in  promoting 
its  use  is  apparent.  The  success  of  the  MVS  strategy  is  reflected  in  the 
enormous  amount  of  hardware  installed  by  the  users:  practically  all  have 
multiple  systems  installed.  (This  hardware/software  relationship  will  be 
explored  later  in  a  case  study  using  Singer  as  an  example.) 

The  complex  hardware/software  support  requirements  of  the  three  main 
software  vendors  (MPG,  SAS  &  MSA)  include  all  IBM  systems  going  back  to 
360/370  and  operating  systems  going  back  to  PCP.  That  this  places  a  signifi- 
cant burden  upon  the  software  vendors  will  become  apparent  as  we  analyze 
software  development  problems  later  in  the  report. 
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MPG  has  restricted  itself  to  support  of  IBM  mainframe  systems  in  the 
past,  but  it  is  currently  being  asked  by  its  clients  to  support  the  IBM 
Personal  Computer.  At  present,  they  can  build  systems  which  pass 
RAMIS  II  requests  using  the  PC.  They  stated  that  with  the  increased 
use  of  PCs,  there  is  a  definite  possibility  for  a  "RAMIS-type"  system 
for  micros.  INPUT  has  not  confirmed  that  the  project  has  been  funded. 

SAS  is  confronted  with  the  same  complexity  of  target  systems  support 
as  the  other  mainstream  IBM  vendors.  They  have  made  plans  to 
support  minicomputers  with  SAS  and  SAS/Graph.  At  present,  SAS  has 
been  announced  for  Data  General,  but  it  is  no  secret  that  other  minis 
have  been  targeted,  and  a  separate  development  group  called  "Portable 
Systems"  has  been  established  with  10+  people  (which  by  SAS  standards 
is  a  large  group). 

MSA  currently  does  80%  of  its  business  with  users  of  IBM  mainframes 
and  20%  with  other  mainframe  customers.  It  is  our  understanding  that 
the  percent  of  IBM  business  has  been  steadily  increasing  and,  while 
there  is  no  indication  products  for  other  mainframes  will  be  discon- 
tinued, the  emphasis  is  definitely  on  IBM.  (Due  to  the  packages  being 
written  in  COBOL  and  the  relative  stability  of  the  operating  systems  of 
other  mainframe  vendors,  support  for  non-IBM  systems  is  not  too  much 
of  a  problem.)  MSA  has  recognized  the  desirability  of  entering  the 
microprocessor  software  market  by  acquiring  Peachtree  Software, 

Sundance  does  not  necessarily  specialize  in  IBM  System  38  and  34.  In 
fact,  one  of  the  principal's  main  experiences  had  been  with  large-scale 
IBM  systems,  both  as  an  IBM  employee  and  as  president  of  a  major 
insurance  industry  research  organization.  However,  Sundance  is  finding 
that  their  primary  business  has  been  falling  in  those  areas.  We  think 
this  is  significant  in  so  far  as  both  the  market  for  custom  systems  and 
IBM's  low-end  strategy  is  concerned.  The  message  seems  clear: 
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While  the  System  38  and  the  low  end  of  the  43XX  series  overlap 
in  terms  of  power,  the  43XX,  regardless  of  operating  system, 
has  the  ability  to  grow.  Even  the  first-time  user  recognizes  this 
and  probably  anticipates  growth  at  time  of  purchase. 

On  the  other  hand.  System  38  users  do  not  see  a  growth 
pattern.  The  system  will  do  what  they  anticipate  they  want 
done.  Therefore,  they  feel  comfortable  having  an  outside  organ- 
ization develop  and  install  their  primary  applications.  They  do 
not  anticipate  that  they  will  require  systems  personnel. 

This  difference  in  customer  attitude  can  be  attributed  not  only 
to  the  way  IBM  sells  the  systems  but  also  to  the  basic  hard- 
ware/software architectures  of  the  two  systems.  (This  will  be 
discussed  in  more  detail  when  IBM's  organization  for  systems 
sales  and  software  support  is  analyzed.) 

HARDWARE/SOFTWARE  DEVELOPMENT  SYSTEM  ORGANIZATION  - 
DESCRIPTION  AND  EVALUATION 

As  would  be  expected,  most  of  the  EDP  departments  use  TSO  as  their  primary 
interactive  facility  for  development,  and  the  software  vendors  use  CMS. 
hlowever,  it  was  somewhat  surprising  that  most  of  the  EDP  departments  had 
followed  IBM's  recommendations  and  dedicated  systems  for  development  (at 
least  during  prime  shift).  This  Is  another  factor  contributing  to  hardware 
sales,  and  it  Is  impressive  to  see  the  end  results  of  a  major  IBM  strategy  which 
has  been  successful.  (This  will  be  discussed  in  more  detail  when  the  produc- 
tivity problem  is  analyzed.) 

The  target  system/software  used  for  applications  development  is  summarized 
in  Exhibit  IIi-5  and  the  hardware  in  Exhibit  lii-6. 


-  40  - 


EXHIBIT  III-5 
TARGET  SYSTEM/SOFTWARE 


COMPANY 

HARDWARE 

OPERATING 
SYSTEM(S) 

SCE 

3081 
3033 

MVS 

Singer 

3033 

MVS 

CIC 

3081 
3033 

MVS 

MH 

3033 
3032 

MVS 

CSS 

1 

3033 

MVS 

UNC 

4341  II 

MVS 

NS 

3081 
3033 

MVS 

Software  Vendors 

MPG 

30XX 
43XX 
370/360 

All  Mainstream 

IBM 
(DOS/OS /VS) 

SAS 

IBM  (Same  as  Above) 
DC  (Others  Planned) 

DOS/VSE 
OS/VS  (PGP— ►MVS) 
CMS 

MSA 

80%  IBM  (Same  as  Above) 
20%  Other  Mainframes 
Starting  Micros 

"Practically  AH  IBM" 
As  Required 
Plus  DBMSs 

Sundance 

System  38,  34,  Apple 

"As  Required" 
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EXHIBIT  III-6 
HARDWARE/SOFTWARE  DEVELOPMENT  SYSTEM 


COMPANY 

HARDWARE 
SYSTEM(S) 

PRIMARY 
INTERACTIVE  SYSTEM 

SCE 

3033  MP 
(Dedicated) 

(Information  Center) 

TSO/ISPF 

Singer 

Amdahl  V6 
(Dedicated) 

TSO,  Wylbur 

CIC 

3033  MP 
[  ueuicateu  j 

TSO,  CMS 
tmpnasizeuj 

MH 

4341 
(Dedicated) 

CMS, 

MVS /Wylbur  Under  VM 

CSS 

3033  , 

TSO 

(Considering  Other  Alternatives) 

UNC 

4341  II 

TSO 

NS 

3081 
3033 

TSO 

Software  Vendors 

MPG 

4341  II 
4331 
NCSS  3200 

CMS 
DOS/VSE 
CSS 

SAS 

158  AP 
4341  II 

MVS/SP 
CSM 

MSA 

3081 
3033 
4341  &  4341  II 
4331 

TSO 

CMS 
CMS 
SSX/VSE 
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•  The  evolution  of  the  development  systems,  as  described  by  the  respondents, 
provides  some  insight  into  IBM  success  in  its  software/hardware  strategy, 
which  is,  fundamentally,  to  emphasize  the  need  for  their  system  software 
offerings  with  the  knowledge  that  hardware  sales  will  follow. 

Southern  California  Edison  is  an  excellent  example  of  an  organization 
on  the  leading  edge  of  IBM's  recommended  strategy  for  improving 
systems  development  productivity.  The  development  systems  have 
evolved  on  IBM's  timeframe. 

At  present  a  3033  MP  with  TSO/ISPF  is  dedicated  to  system 
development  and  maintenance. 

This  year  the  Computer  User  Services  Department  (information 
center)  was  established,  and  it  now  has  a  3033  UP  dedicated  to 
user  development  and  prototyping. 

Since  SCE  has  a  single  3081  dedicated  to  run  its  network  (appli- 
cations), more  computer  power  is  devoted  to  systems  develop- 
ment and  maintenance  than  is  devoted  to  running  the  business. 

Singer  is  in  the  process  of  decentralizing  what  was  formerly  a  highly 
centralized  computer  communications  network.  What  was  formerly  the 
main  computer  center  for  the  enterprise  now  supports  a  single  divi- 
sion's processing.  That  division,  Kearfott,  was  the  interview  site. 

At  present,  a  purchased  Amdahl  V/6  is  dedicated  to  development 
using  both  TSO  and  Wylbur.  Some  former  user  divisions  still  use 
the  system  for  development. 

Singer  was  reluctant  to  go  to  MVS  for  a  number  of  years  during 
its  centralized  operation  (electing  to  stay  with  OS/MVT). 
During  that  period  an  evaluation  of  TSO  and  Wylbur  resulted  in 
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Singer's  being  one  of  the  first  Wyibur  users  in  the  eastern  part  of 
the  United  States. 

Under  OS/MVT  development  was  done  using  Wyibur  on  an  IBM 
370/165  and  168,  and  those  systems  were  also  used  for  produc- 
tion. These  two  systems  served  the  entire  enterprise  for  both 
domestic  and  European  operations  of  the  company. 

Seven  years  ago  a  proposal  was  made  to  install  a  single  Amdahl 
V6  to  do  all  data  processing,  both  production  and  development, 
for  the  entire  company.  Now  such  a  processor  is  used  for 
systems  development  for  a  single  division.  It  is  suspected  that 
the  enormous  increase  in  processing  requirements  can  be  attrib- 
uted in  no  small  part  to  an  MVS/TSO  environment.  The  overall 
economics  of  decentralized  processing  and  systems  development 
will  be  explored  in  the  Singer  Case  Study  -  Chapter  VI,  Section 
C. 

Continental  Insurance  Companies  has  a  dedicated  3033MP  devoted  to 
systems  development  under  VM.  CMS  is  the  preferred  interactive 
facility,  but  TSO  still  runs  under  MVS  under  VM.  The  interviewee  was 
not  familiar  with  how  the  system  evolved,  but  he  assumes  it  evolved 
"as  IBM  shifted  emphasis."  A  dual  3081  is  used  for  production. 

McGraw-Hill  has  a  dedicated  4341  for  development  and  the  Decision 
Support  Systems  function  (information  center).  CMS  is  used  as  the 
interactive  facility  under  VM,  but  Wyibur  is  also  provided  in  a  VM/MVS 
hierarchical  environment.  The  development  system  was  brought  in 
essentially  with  the  new  DP  management  team  which  was  brought  in 
when  J.J.  Ryan,  the  Senior  Vice  President  of  Information  Systems  and 
Technology,  was  hired  three  to  four  years  ago.  The  Decision  Support 
Systems  function  is  relatively  new  and  is  just  beginning  to  install  user 
user-oriented  tools.    It  is  probable  that  this  will  result  in  an  upgrading 
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(or  separation)  from  the  4341.  Production  systenns  at  MH  are  a  3033, 
3032  and  370/158. 

Citizens  and  Southern  has  two  3033s  which  are  loosely  coupled  and 
there  is  no  indication  of  an  attempt  to  dedicate  one  or  the  other  for 
development.  TSO  is  currently  being  used  as  the  interactive  facility, 
but  it  is  considered  "expensive,"  and  other  alternatives,  including 
Wylbur,  are  being  considered.  ^ 

The  University  of  North  Carolina  has  a  single  4341  1!  which  is  being 
used  for  both  production  and  development  under  MVS/TSO.  They  are 
finding  the  systems  to  be  a  "huge  resource  burner"  and  the  future  is 
questionable  as  they  proceed  with  their  conversion  from  Univac. 

Southern  Railway  (NS)  has  used  TSO  for  the  last  10  years.  They  cur- 
rently have  a  3081  and  two  3033s  installed  in  a  network  including  450 
minis  and  micros.  They  operate  under  MVS/JES-3,  and  no  indication 
was  given  that  any  system  has  been  specifically  isolated  for  develop- 
ment. However,  it  is  likely  that  the  normal  mode  of  operation  tends  to 
channel  most  development  work  to  a  single  system,  even  if  develop- 
ment and  production  can  cohabit.  The  statement  was  made  that  "pro- 
grammers can  really  screw  a  system  up,"  so  they  have  probably  had 
experience. 

Mathematica  has  a  4341  il  under  VM/CMS  with  all  IBM  OS/VS  operating 
systems  on  it  for  systems  integration  and  testing.  In  addition,  all 
administrative  systems  (written  in  RAMIS)  run  on  that  system. 

As  Mathematica  has  developed  products  for  certain  specific 
hardware/software  systems,  they  have  seen  fit  to  install  them 
during  the  development  process  rather  than  using  the  4341  II  as 
a  "vehicle"  system. 
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For  that  reason,  a  4331  is  installed  for  development  and  mainte- 
nance of  DOS/VSE  and  an  NCSS  3200  is  installed  under  the  CSS 
operating  system. 


SAS  Institute  has  a  370/158  model  3  AP  installed  under  MVS/SP  and  a 
4341  II  running  under  VM/CMS,  which  has  all  of  the  other  IBM  operat- 
ing systems  under  which  SAS  runs. 

When  SAS  was  small  they  had  to  rent  time  for  development,  and 
it  was  a  very  bad  experience.  They  feel  it  is  necessary  for  even 
a  small  software  vendor  to  be  an  IBM  customer  if  they  are  to 
properly  and  economically  support  their  customers.  (They  are 
not  yet  at  the  point  where  they  can  install  all  of  the  minis  they 
intend  to  support  under  "Portable  Systems,"  but  this  is  not 
viewed  as  a  problem.) 

-4  -       They  also  feel  that  by  bringing  in  new  IBM  operating  systems 
and/or  selectable  modules  they  can  serve  as  a  testing  ground. 

Management  Science  America,  because  of  its  size  and  the  diversity  of 
its  product  offerings,  has  a  large  array  of  hardware  installed  for 
development  purposes. 

They  have  processors  from  the  3081  down  to  the  4331  installed 
under  both  MVS  and  VM,  permitting  testing  under  most  past 
operating  systems  and  many  specific  releases.  Both  TSO  and 
CMS  are  used  for  program  development  and  maintenance. 

They  installed  an  early  4331  under  SSX/VSE  which  serves  as  an 
IBM  test  site  for  that  system. 

When  MSA  first  got  started,  they  had  a  batch  360/50  plus  the 
use  of  client  locations.     Then  they  started  using  a  service 
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bureau,  which  was  not  satisfactory.  They  soon  concluded  that 
they  must  have  their  own  development  systems  because  of  the 
complex  number  of  combinations  and  interfaces  and  the  need  to 
understand  their  customers'  great  variety  of  operating  systems 
environments. 

Sundance  (not  shown  on  Exhibit  IIi-5)  is  in  a  growth  phase  where  they 
have  to  use  either  the  client  site  or  go  to  a  service  bureau  for  System 
38  and  34  development  time. 

This  actually  is  not  too  bad  for  Sundance  since  their  clients 
expect  them  to  develop  and  install  custom  systems  on  a  turnkey 
basis.  The  clients  expect  to  see  them  on-site  during  both  devel- 
opment and  installation.  ^' 

The  only  in-house  computer  equipment  Sundance  has  are  two 
Apples  and  an  IBM  Displaywriter.  They  are  used  for  both 
internal  office  and  commercial  processing  as  well  as  for 
development  purposes. 

•  The  respondents  were  asked  to  rate  their  current  development  system  for  a 
number  of  attributes.  A  four-level  system  was  employed,  "I"  being  outstand- 
ing and  "4"  being  poor.  Users  seemed  to  be  more  willing  to  rate  their  develop- 
ment systems  than  vendors,  who  uniformly  felt  their  multiple  systems  could 
not  be  adequately  rated  by  an  average  factor. 

User  ratings  are  summarized  in  Exhibit  I1I-7.  These  ratings  are  basic- 
ally for  one  MVS/TSO  dedicated  development  system.  There  are  not 
too  many  surprises  in  the  ratings;  they  generally  conform  to  those 
received  for  IBM  systems  software.  Documentation,  maintenance,  and 
training  are  rated  high  (an  average  of  1.4,  1.75  and  1.8  respectively), 
while  efficiency  and  ease  of  installation  are  rated  lower  (2.8  and  3.0 
respectively).  Individual  respondents  had  the  following  comments: 
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EXHIBIT  III-7 


RESPONDENTS'  EVALUATION  OF  THEIR  DEVELOPMENT  SYSTEMS 


SCE 


Singer 


CIC 


MH 


CSS 


UNC 


NS 


Mean 
Response 

1  =  Outstanding 

2  =  Good 

3  =  Fair 

4  =  Poor 


1 

(Hardware) 
2 


No  Rating,  Deemed  Too  Complex  and  Little  Knowledge 


2 

1 

1 

1 

1 

2 

1 

1-2 

1 .  375 

3 

4 

2 

3 

1 

2 

3 

Mixed 

2.  375 

3 

NA 

2 

NA 

1 

1 

NA 

2 

1.8 

1.667 


3 

3 

3 

2 

2 

2 

3 

2.5 

4 

2 

3 

2 

2 

1 

2 

2.5 

No  Rating  on  Others,  See  Comments 


2.8 


3.0 

2.0 

2.  5 

1.4 

1.8 

1.75 

2.  125 

-  48  - 


INP 


Singer  was  pleased  with  the  reliability  of  the  hardware,  but  they 
had  just  had  problems  installing  ADRS  for  users.  They  were  not 
happy  with  the  installation,  which  took  six  months.  The  respon- 
dent stated:  "IBM  software  is  bad;  none  of  it  goes  in  in  less  than 
six  months." 

C&S  is  not  happy  with  the  performance  or  operational  aspects  of 
their  system,  and  this  is  reflected  in  an  overall  rating  of  "fair" 
for  the  entire  system.  As  mentioned  previously,  they  feel  TSO 
is  expensive  and  are  seeking  alternatives. 

University  of  North  Carolina  is  in  the  throes  of  conversion  and 
had  the  following  comments:  I)  "The  hardware  has  never  been 
down  in  nine  months,"  2)  "The  system  is  a  high  resource  user,"  3) 
"In  installing  the  system  a  ten-day  plan  took  three  months,"  and 
4)  they  were  "generally  pleased." 

Southern  Railway  (NS),  which  has  the  most  mature  development 
system  since  they  have  had  TSO  for  ten  years,  stated  the  fol- 
lowing: I)  efficiency  was  not  of  much  concern  since  they  de- 
signed the  system  with  sufficient  power;  2)  most  problems  are 
caused  by  data  and  not  programs  (Southern  runs  development  on 
production  systems);  3)  problems  are  not  as  frequent,  but  they 
are  more  difficult  to  solve;  and  4)  they  did  not  want  to  rate 
because  any  down  time  was  bad  for  either  operations  or  develop- 
ment personnel,  who  all  depend  on  the  system. 

Software  vendors  have  a  different  perspective  on  development  systems 
than  users  for  the  following  reasons: 

They  usually  are  responsible  for  many  of  the  problems  since  they 
must  create  a  complex  operating  environment,  and  they  try  to 
force  failures. 
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Even  when  things  go  wrong  with  the  systenn,  the  experience  has 
some  value  in  letting  thenn  know  what  to  expect  when  they 
install  at  the  user  site. 

Software  vendors  take  pride  in  being  able  to  handle  any  system, 
and  they  are  sensitive  to  the  problems  of  new  releases.  They  do 
not  mind  testing  new  operating  systems  and  selectable  modules; 
it  permits  them  to  get  their  products  installed  faster. 

4.       DEVELOPMENT  FACILITIES  AND  ENVIRONMENTS 

•  INPUT  asked  questions  concerning  the  establishment  of  information  centers, 
availability  of  terminals  for  systems  personnel,  and  user  involvement  in  devel- 
opment activities.  The  results  for  EDP  departments  are  summarized  in 
Exhibit  I1I-8. 

Only  two  companies,  Southern  California  Edison  and  McGraw-Hill,  have 
established  and  funded  information  centers,  and  both  of  them  were 
formed  during  the  last  year.  However,  the  concept  of  information 
centers  has  obviously  become  fashionable.  Following  is  the  current 
status  of  the  companies  interviewed. 

SCE  has  the  most  ambitious  information  center.  It  has  estab- 
lished a  Computer  User  Services  department  with  a  staff  of  50 
people  and  a  dedicated  3033  development  system. 

Singer,  while  it  does  not  have  an  information  center,  has  a 
director  of  operations  running  education  courses  and  consulting 
with  end  users  so  they  can  bypass  the  MIS  department  and 
develop  their  own  systems. 
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00 


H 

X 
X 
LU 


Z 

LU 


O 

> 
Z 
LU 

H 
Z 

LU 
CL 

o 

-J 

LU 
> 
LU 

Q 


DEVELOPMENT 
TOOLS 

FOCUS, 
MARK  IV 

ADRS 

SAS 
RAMIS 
Easytrieve 
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CIC  has  a  stated  corporate  policy  of  getting  end  users  involved 
in  the  systenns  development  process.  While  they  don't  have  an 
information  center,  users  are  beginning  to  work  with  their 
systems  departments  in  learning  how  to  employ  user  friendly 
tools. 

MH  has  established  a  Decision  Support  Services  function  which 
includes  the  information  center.  It  is  anticipated  that  such  end 
user  involvement  could  result  in  full-time  systems  personnel  in 
user  departments. 

C&S  has  established  a  Data  Decisions  department  of  four  people 
who  are  establishing  standards  for  personal  computers.  In  this 
activity  they  are  beginning  to  perform  some  of  the  functions  of 
an  information  center.  (The  Vice  President  of  Operations  was 
less  than  enthusiastic  about  this  activity  insofar  as  he  antici- 
pates PCs  tying  into  his  network.) 

UNC  has  a  classic  systems  environment,  and  it  is  not  anticipated 
that  an  information  center  will  be  established  in  the  near 
future.  However,  Systems  and  Procedures  personnel  do  work 
closely  with  end  users,  some  of  whom  are  quite  sophisticated  in 
the  use  of  computers. 

Southern  Railway  (NS)  has  been  considering  the  establishment  of 
an  information  center.  The  Assistant  Vice  President  of  MIS  had 
it  included  in  his  budget  for  1982,  but  it  was  eliminated  because 
of  the  planned  merger  with  Norfolk  and  Western. 

It  seems  apparent  that  IBM  is  promoting  the  concept  of  informa- 
tion centers  as  a  means  of  establishing  EDP  department  involve- 
ment and  control  over  end  user  systems  development.  These 
have  been  traditional  problems  from  the  early  days  of  time- 
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sharing:  IBM  has  account  control  through  EDP  departments,  but 
other  vendors  sell  directly  to  end  users.  The  situation  with 
personal  computers  posed  a  real  threat  to  IBM  account  control, 
and  information  centers  are  a  means  to  get  around  this. 

The  trend  in  terminals  is  toward  one  for  each  programmer/analyst. 
Three  of  the  seven  companies  already  have  this  ratio,  and  SCE,  which 
currently  has  two  development  employees  per  terminal,  has  a  plan  to 
have  a  terminal  per  programmer/analyst  by  the  end  of  the  year.  With 
this  trend  comes  the  placement  of  terminals  at  the  work  station  rather 
than  in  centralized  locations. 

it  appears  that  EDP  departments  have  accepted  the  fact  that  a  certain 
amount  of  computer  systems  development  is  going  to  be  done  by  end 
users.  This  appears  to  be  the  result  of  two  significant  changes  in 
attitude  during  the  last  few  years: 

EDP  personnel  have  come  to  realize  that,  like  it  or  not,  users  do 
have  a  rather  clear  idea  of  what  they  want  to  do.  And,  more 
important,  users  are  going  to  do  what  they  want  to  do,  with  or 
without  the  EDP  department. 

IBM  has  decided  a  dual  approach  to  the  marketplace  is  required 
because  of  the  trends  in  distributed  processing  and  office  auto- 
mation. Specifically,  there  is  an  end  user  market  which  is 
concerned  about  the  most  easily  installed  and  cost-effective 
equipment  available,  regardless  of  vendor  name.  This  end  of  the 
market  can  only  be  satisfied  by  products  the  customer  under- 
stands and  can  install  himself  without  being  dependent  upon 
IBM.  In  the  past,  IBM  has  practically  insisted  upon  a  parent- 
child  relationship  with  even  its  most  sophisticated  customers. 
They  now  appear  willing  to  relinquish  systems  control  in  order  to 
place  hardware. 
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The  current  development  tools  provided  to  end  users  are  just  beginning 
to  emerge,  but  the  fourth  generation  languages  are  apparent,  and  the 
easy-to-use  personal  computers  have  given  impetus  to  providing  tools 
to  users  even  where  they  are  not  specifically  mentioned,  as  in  Exhibit 
III-7.  Every  company  interviewed  was  sensitive  to  the  personal  com- 
puter revolution  and  Its  possible  Impact  on  conventional  systems  devel- 
opment. This  impact  of  personal  computers  will  be  detailed  later  in 
the  report.  -  - 

•  The  questions  relating  to  information  centers  and  distributed  development  are 
not  specifically  related  to  vendors.  However,  several  of  the  vendors  had 
pertinent  comments  upon  the  information  center  concept. 

SAS  felt  that  information  centers  could  result  in  explosive  growth  for 
Its  products  because  users  would  find  centers  easy  to  use  and  informa- 
tion center  system  personnel  would  be  able  to  satisfy  user  requirements 
for  information.  While  this  was  obviously  good  for  SAS,  the  respondent 
had  the  following  observations. 

"IBM  is  pushing  (the  Information  center  concept),  and  customers 
are  doing  as  they  say.  The  trend  among  IBM  customers  is 
clearly  discernible." 

"Information  centers  are  really  a  band-aid;  they  do  not  solve 
the  problems  involved  with  getting  the  information  to  the  people 
who  need  it.  That  is  the  real  job  of  the  computer  professional, 
and  those  who  attempt  to  abdicate  that  responsibility  aren't 
going  to  have  jobs." 

•  Since  the  products  and  services  of  the  software  vendors  depend  upon  a  produc- 
tive and  satisfied  staff,  all  of  the  vendors  provided  an  excellent  working 
environment  for  the  development  staff.  As  part  of  the  environment  there  was 
at  least  one  terminal  per  professional  employee. 
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D.       CONCLUSIONS  CONCERNING  RESPONDENT  CHARACTERISTICS 


•  During  the  last  10  years  an  enormous  investment  has  been  made  in  hardware 
and  software  to  support  the  systems  development  process. 

There  are  large-scale  IBM  systems  dedicated  to  support  of  the  systems 
function. 

Terminals  to  support  interactive  program  development  and  mainte- 
nance are  commonplace  at  most  programmer/analyst  workstations. 

•  Computer  processing  power,  in  one  form  or  another,  is  being  distributed  closer 
to  end  users.  ^ 

The  number  of  user  terminals  has  increased  sharply  with  many  com- 
puter installations  servicing  thousands  of  terminals. 

Southern  California  Edison  has  2,200  terminals  installed. 

Citizens  and  Southern  will  have  4,000  installed  by  the  end  of 
next  year. 

Distributed  processing,  in  the  form  of  minicomputers  con  lected  to 
centralized  IBM  mainframes,  have  proliferated. 

Continental  Insurance  has  approximately  200  Computer  Auto- 
mation minis  in  its  network. 

Southern  Railway  has  350  Data  General  processors  tied  into  its 
central  IBM  installation. 
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Where  processing  is  not  distributed  in  an  orderly  manner  (under  the 
central  control  of  the  EDP  department),  it  may  become  decentralized 
and  chaotic. 

Singer  went  from  a  single  centralized  location  to  12  locations 
where  IBM  43XX  systems  are  installed.  At  the  same  time,  it 
retains  a  central  location  with  four  times  the  processing  power 
it  had  10  years  ago.  ~ 

Office  automation  equipment  has  become  computerized  to  the 
degree  that  many  business  applications  can  be  done  as  a  by- 
product of  word  processing. 

Personal  computers  which  weren't  invented  10  years  ago  have 
become  a  fact  of  life  in  the  business  environment,  and  their  use 
is  growing  completely  out  of  the  control  of  the  EDP  department. 

This  exposure  of  end  users  to  computer  technology  has  heightened  not  only  the 
demands  for  new  applications  but  has  also  focused  attention  on  the  produc- 
tivity problem  in  the  conventional  systems  development  process.  Users  will 
no  longer  take  no  for  an  answer;  they  feel  they  are  more  in  control  of  their 
own  destinies. 

EDP  departments  have  been  forced  to  get  end  users  involved.  We  now  see  an 
environment  where  user  participation  in  the  development  process  is  being 
encouraged  either  through  information  centers  or  planned  participation  in  the 
conventional  systems  development  process.  It  does  not  make  any  difference 
whether  EDP  departments  were  forced  to  accept  user  involvement  or  whether 
they  sincerely  want  end  users  involved  -  the  environment  has  changed  signifi- 
cantly from  ten  years  ago. 

Hardware  and  software  vendors  along  with  various  consulting  organizations 
have  sensed  an  enormous  potential  market  for  some  time,  and  an  enormous 
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array  of  hardware,  software,  and  methodological  "solutions"  to  the  produc- 
tivity problem  have  been  proposed. 

The  results  of  all  of  this  were  summarized  in  the  research  objectives  prepared 
by  CDL:  ".  .  ,  the  software  backlog  is  increasing  cumulatively,  and  with  rising 
personnel  costs  and  a  shortage  of  programmers,  it  has  become  more  and  more 
expensive  and  time-consuming  to  develop  computer  programs." 

It  is  possible  to  conclude  not  only  that  the  productivity  problem  has  not  been 
solved,  but  that  it  is  not  even  understood.  INPUT  believes  that  it  is  much 
more  important  to  understand  the  problem  than  it  is  to  understand  what 
people  are  currently  doing  about  it. 
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IV   SOFTWARE   DEVELOPMENT  PRODUCTIVITY 


IV       SOFTWARE  DEVELOPMENT  PRODUCTIVITY 


A.  INTRODUCTION 

•         Before  delving  into  recent  analysis  of  software  development  productivity,  it  is 
desirable  to  place  the  current  problems  in  historic  perspective, 

i 

Early  computer  engineers  did  not  anticipate  that  computer  programs 
would  fail.  The  hardware  might  fail,  but  the  computer  would  only  do 
what  you  told  it.  It  was  assumed  that  if  you  knew  what  you  wanted  to 
do  the  computer  would  do  it.  These  understandably  naive  assumptions 
have  proven  deceptive  for  two  reasons: 

Initially  telling  the  computer  what  to  do  (programming)  became 
extremely  tedious  with  problems  of  any  complexity.  A  great 
deal  of  attention  has  been  paid  to  programming  and  outstanding 
progress  has  been  made  in  this  area. 

At  the  present  time,  the  most  significant  problem  is  not  in 
telling  the  computer  what  to  do,  it  is  in  telling  other  people 
what  you  want  the  computer  to  do  or  in  what  you  are  having  the 
computer  do.  This  problem  is  increasing  exponentially  as  more 
people  become  involved  with  computer  systems  and  as  their 
expectations  become  more  complex.  Attempts  to  solve  this 
problem  have  not  been  successful. 
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An  early  computer  engineer  at  IBM  who  was  acquainted  with  von 
Neumann  at  Princeton  was  adamant  that  he  would  never  program 
computers  at  all.  The  thought  was  to  build  the  computer  to  do  what 
you  wanted  it  to  do. 

He  designed  an  early  IBM  computer  which  never  became  a 
product.  It  was  essentially  an  attempt  at  micro-coding,  and  an 
observer  within  IBM  has  recently  stated,  "No  one  understood  it." 

The  von  Neumann  architecture  has  prevailed  to  this  day,  and  the 
concept  of  the  general  purpose  computer  which  can  do  anything 
you  tell  it  to  do  through  programming  is  still  with  us.  Both  of 
these  phenomena  have  contributed  to  today's  problems  well 
beyond  the  time  that  they  were  either  necessary  or  desirable 
from  a  technological  point  of  view. 

•  It  is  also  necessary  to  consider  the  current  view  of  the  role  into  which  the 
programmer/analyst  has  been  cast.  Two  recent  events  serve  to  illustrate  this 
view: 

A  recent  industry  publication  article  stated  that  a  particular  company 
had  found  that  the  best  means  for  selection  of  programmers  was  the 
clerical  aptitude  test.  This  may  be  true,  but  it  may  also  be  part  of  the 
problem.  The  tools  which  facilitate  "telling  the  computer  what  to  do" 
may  limit  the  development  of  personnel  who  are  capable  of  determin- 
ing what  should  be  done. 

A  delegation  of  computer  systems  personnel  from  the  United  States 
recently  visited  China  and  were  confronted  with  Chinese  officials  who 
expressed  great  interest  in  the  problems  associated  with  software 
development.  They  had  heard  that  programming  was  labor-intensive 
and  felt  they  might  have  the  manpower  to  solve  the  problem. 
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It  is  possible  that  computers  may  be  creating  more  jobs  than  they  are 
replacing  (certainly  the  personnel  shortage  in  computer-related  jobs 
still  exists),  and  some  would  even  consider  this  to  be  desirable.  How- 
ever, the  specific  shortage  in  the  software  development  process  is 
slowing  the  application  of  technology,  and  the  paradox  in  the  current 
view  of  the  role  of  the  programmer/analyst  is  apparent.  Perhaps  a  new 
paradigm  of  software  development  is  required.  ~ 

•  Since  this  study  concentrates  on  software  development  for  IBM  systems,  it  is 
helpful  to  understand  the  evolution  of  the  target  hardware/software  systems 
with  which  we  are  dealing. 

In  1963  IBM  surveyed  all  its  major  customers  (less  than  700  installa- 
tions) concerning  the  relative  importance  of  various  attributes  of 
systems  software.  At  that  time  "operating  systems"  had  not  been 
invented,  so  some  of  the  software  systems  seem  somewhat  quaint,  but 
the  results  are  quite  clear,  as  shown  in  Exhibit  IV- 1 . 

The  clients  were  asked  to  rank  the  attributes  in  order  of  impor- 
tance. While  many  things  can  be  concluded  from  the  rankings, 
clearly  "ease  of  use"  is  the  most  important  attribute. 

Ease  of  use  was  presented  as  a  dual  attribute  associated  with 
programming  and  with  the  operational  aspects  of  the  package.  - 
It  was  clearly  top  ranked  on  seven  of  the  eight  system  compon- 
ents evaluated,  and  it  tied  with  speed  of  operation  as  being  the 
most  important  attribute  of  a  sort  package. 

The  mean  ranking  of  the  attributes  reveals  that  "ease  of  use  - 
programming"  was  the  most  important  single  attribute  associ- 
ated with  system  software,  "speed  of  operation"  was  second,  and 
the  quality  of  the  "documentation"  was  third. 
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EXHIBIT  IV-1 

RANKINGS  OF  SYSTEM  SOFTWARE  ATTRIBUTES 

(IBM  Study  -  1963) 
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These  rankings  were  a  clear  expression  of  the  qualities  IBM's 
major  customers  wanted  to  see  in  the  programming  systems  for 
the  new  product  line  (Systems/360).  With  this  mandate  from  its 
customers,  IBM  created  OS/360  which  at  that  time  was  the 
slowest  and  most  difficult  to  use  system  which  had  ever  been 
developed.  Only  the  documentation  has  ever  been  rated  "good," 
and  that  in  later  questionnaires. 

Over  nearly  two  decades,  OS/360  has  evolved  with  MVS,  which  is 
now  the  main  interface  which  IBM  customers  have  with  their 
computers.  It  is  not  easy  to  use;  it  is  not  fast;  and  its  complex- 
ity contributes  to  the  problems  associated  with  user  software 
development.  / 

IBM  did  not  anticipate  that  programming  support  for  System  360  was  going  to 
present  the  cost  or  scheduling  problems  that  it  did.  Indeed,  it  is  to  IBM's 
credit  that  the  system  was  successfully  implemented  and  worked.  It  was  the 
biggest  software  systems  development  project  ever  undertaken,  even  though 
IBM  management  did  not  realize  it  at  the  time.  The  facts  that  it  slipped 
schedule  numerous  times  and  cost  at  least  10  times  as  much  as  budgeted  were 
frustrating  to  IBM  management,  and  the  delivered  product  was  frustrating  to 
IBM  customers.  It  is  important  to  understand  how  this  happened. 

Dr.  Frederick  P.  Brooks,  Jr.,  who  moved  from  project  leader  of  hard- 
ware development  on  System/360  to  manage  the  programming  effort  on 
OS/360,  attempted  to  explain  the  problems  of  software  engineering  in 
his  1975  essays.  The  Mythical  Man-Month.  He  made  some  good  points 
in  his  book  which  are  well  known  and  will  not  be  repeated  here.  It  is 
important  to  recognize  more  fundamental  considerations  concerning 
the  OS/360  experience. 
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The  first  is  to  seriously  question  the  wisdom  of  IBM  management 
in  piecing  Dr.  Brooks  in  charge  of  OS/360  development.  Com- 
puter architects  are  especially  disdainful  of  software  to  begin 
with  because  they  view  it  as  a  necessary  evil.  (Gene  Amdahl 
always  deplored  the  fact  that  software  ruined  his  archi- 
tecture.) Three  levels  of  IBM  management  above  Dr.  Brooks 
were  removed  from  their  positions  because  of  the  problems  with 
the  OS/360  development  while  he  was  fortunate  enough  to 
escape  to  the  academic  world. 

The  user's  problem  with  OS/360  was  that  it  did  not  satisfy  their 
requirements.  It  only  showed  that  computer  architects  and 
engineers  did  not  understand  what  "ease  of  use"  meant  to  users 
of  the  combined  hardware/software  systems. 

The  designers  and  implementors  of  the  system  software  did  not 
understand  either  the  problems  of  the  users  or  the  potential 
solutions  to  these  problems.  For  example,  GE  announced  its 
intent  to  implement  a  data  base  facility  (Integrated  Data  Store  - 
IDS)  for  its  computer  systems.  This  was  brought  to  the  atten- 
tion of  the  Director  of  Programming  Systems  in  IBM.  The  reply 
was  that  such  a  facility  was  not  needed  because  of  ISAM.  This 
is  misunderstanding  at  a  basic  level. 

As  has  been  seen  (Exhibit  IV-I),  IBM  customers  felt  all  computer 
languages  should,  first  and  foremost,  be  easy  to  program.  This 
was  hardly  a  surprising  conclusion.  IBM  decided  at  a  high  level 
in  the  company  that  what  the  customer  really  needed  was  a 
single,  new  language  which  would  satisfy  both  scientific  and 
commercial  programmers  and  replace  FORTRAN  and  COBOL, 
PL/ 1  was  announced  as  a  new  and  "more  complete"  language.  It 
was  not  what  the  customers  had  in  mind,  however,  and  15  years 
later  it  still  is  not  extensively  used  by  IBM  customers. 


-  64  - 


INF 


The  primary  backlog  in  software  development  today  is  in  com- 
mercial applications.  IBM  hardware  and  software  were  designed 
with  the  scientific  and  engineering  user  in  mind,  The  Mythical 
Man-Month  references  systems  which  preceded  System/360. 
The  650,  701,  704,  709,  7090  and  Stretch  computers  are  men- 
tioned. None  of  the  major  commercial  systems  -  1410,  7070  or 
7080  series  -  were  even  mentioned. 

Even  if  OS/360  had  been  delivered  on  time  and  within  budget,  it  was 
not  designed  to  satisfy  user  requirements  in  a  commercial  environment 
(much  less  the  type  of  environment  which  exists  today). 

•  This  history  is  presented  not  to  belabor  the  past  but  because  it  identifies  many 
of  the  problems  which  still  exist  in  the  system's  development  process,  espe- 
cially as  they  relate  to  IBM.  One  other  point  must  be  made:  since  the  early 
days,  IBM  has  discovered  that  system  software  (and  specific  approaches  to 
software  development)  can  sell  a  lot  of  hardware.  A  high  percentage  of  CPU 
cycles  being  executed  on  IBM  hardware  are  being  exercised  by  IBM  provided 
software.  IBM  will  not  adopt  a  strategy  which  severely  disturbs  this  ratio 
between  vendor-supplied  software  and  problem  programs.  In  fact,  it  is 
probable  that  IBM  intends  to  solve  the  user  productivity  problem  by  increasing 
the  ratio  in  favor  of  vendor-supplied  systems. 

B.       SOFTWARE  DEVELOPMENT  PROBLEMS  AND  BOTTLENECKS 

I.        HISTORIC  TRENDS 

•  Since  the  early  1960s  a  major  change  has  been  discernible  in  EDP  budget 
distribution  between  new  development  and  maintenance,  as  shown  in  Exhibit 
IV-2. 
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This  shift,  while  somewhat  understandable,  is  the  cause  for  a  great  deal 
of  consternation  among  both  users  and  vendors. 

Users,  faced  with  a  heavy  backlog,  want  to  free  personnel  from 
maintenance  to  handle  new  development. 

Vendors  want  users  to  bring  up  new  applications  so  they  can 
place  more  hardware. 

Programmers  normally  don't  like  to  work  on  maintenance,  they 
prefer  to  do  new  things.  Since  they  are  in  demand,  they  may 
leave  a  company  where  they  are  required  to  do  maintenance  in 
favor  of  a  new  job  on  a  development  project. 

While  there  has  been  a  significant  shift  toward  maintenance  in  the  systems 
function,  the  actual  development  process  itself  has  remained  remarkably 
stable  since  the  1963  survey  of  IBM  customers  which  was  previously  cited. 
See  Exhibit  IV-3. 

In  1963  practically  all  commercial  systems  were  written  in  autocoder 
(Assembly  language),  and  now  practically  all  are  written  in  COBOL. 
However,  the  percentages  of  time  spent  on  analysis,  coding,  debugging, 
documentation,  and  "other"  have  remained  practically  the  same. 

By  1980,  an  impressive  array  of  productivity  aids  and  approaches  were 
theoretically  available  for  the  development  of  new  systems,  and  yet 
the  overall  systems  development  process  has  evidently  remained  un- 
changed. 
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TIME  USAGE  IN  SYSTEMS  DEVELOPMENT 


Analysis         Coding       Debugging      Docu-  Other 

mentation 


 '  1963 

— ^—  1980 

Note:  Curve  is  Cumulative 
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2.       PRIOR  INPUT  RESEARCH 


•  in  1980,  when  INPUT  conducted  its  major  productivity  study,  EDP  personnel 
were  asked  to  identify  the  most  important  factors  inhibiting  productivity 
improvement.  The  results  are  depicted  in  Exhibit  IV-4. 

Two  of  the  five  most  important  factors  are  personnel-related  (second 
and  fifth).  - 

Two  are  involved  with  techniques  (first  and  third). 

One  is  a  management  issue  (fourth). 

Inadequate  tools,  aids,  and  methodologies  are  not  among  the  five  most 
important  factors. 

•  However,  when  asked  what  the  areas  of  major  importance  are  in  improving 
software  productivity,  the  results  were  as  shown  in  Exhibit  IV-5. 

Processing  tools  and  aids  are  rated  third  most  important. 

Management  and  personnel  issues  dominate  the  other  five  most  impor- 
tant areas.  The  list  of  personnel  motivation,  management  motivation 
and  support,  personnel  training,  personnel  recruitment,  and  manage- 
ment interest  and  training  can  be  summarized  by  stating  that  produc- 
tivity is  a  people  problem. 

While  such  a  summary  may  seem  overly  simplistic,  it  cannot  be  ig- 
nored. There  is  the  implicit  conclusion  that  having  unqualified  person- 
nel (managers  and  programmer/analysts)  may  create  the  problem. 
Consequently  the  personnel  shortage  must  be  approached  with  great 
care;  merely  adding  people  may  inhibit  the  improvement  of  produc- 
tivity. 
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EDP  DEPARTMENT  RESPONDENTS 


When  asked  how  they  felt  generally  about  productivity  in  the  EDP  systenns 
area,  respondents  unanimously  agreed  there  was  a  problem.  While  this  is  not 
surprising,  it  is  significant  that  not  one  person  stated  that  the  problem  was 
being  exaggerated.  Among  the  comments  were: 

"(We)  have  a  long  way  to  go." 

"it  remains  a  problem;  one  might  even  say  it  (productivity)  is  lacking." 

"Very  bad!  It  is  not  measured;  we  do  not  have  the  capacity  to  under- 
stand how  bad  it  really  is." 

"Everything  seems  to  take  longer  than  it  should,  much  longer!" 

When  asked  about  the  primary  problems  and  bottlenecks  without  any  prompt- 
ing from  the  interviewer,  the  responses  fell  into  the  following  categories,  as 
shown  in  Exhibit  IV-6: 

Personnel. 

Tools  and  methodologies. 
EDP  management. 
Environment. 

These  categories  correspond  quite  well  with  the  primary  areas  isolated  by 
previous  INPUT  research.  However,  there  were  some  unusual  perspectives  on 
the  problems. 
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PRIMARY  PROBLEMS  AND  BOTTLENECKS  - 
EDP  DEPARTMENT  RESPONDENTS 


CATEGORY 

COMMENTS 

Personnel 

"Personnel  level  and  availability  is  the  primary 
problem." 

"Lack  of  skilled  personnel."  . 

"Staff  is  not  motivated." 

Tools  &  Methodologies 

"Evaluation  of  tools  &  methodologies  is  a 
problem  in  itself." 

"Lack  of  initiative  in  using  available  tools." 

"Structured  environment  would  drive  good 
people  crazy." 

EDP  Management 

"Lack  of  EDP  management  perception." 

"DP  management  problems." 

-  "Don't  manage  and  don't  know  how." 

-  "Tend  to  be  technically  oriented." 

-  "Must  understand  business  and  user 

requirements." 

Environment 

"The  EDP  function  stands  in  the  way  of  prog- 
ress; they  should  help." 

"The  government  (management  in  the  case  of 
UNC)  is  the  problem  because  of  personnel 
policies." 

"The  complexity  of  the  operating  system  and 
development  environment  (is  the  primary 
problem) . " 
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There  is  an  indication  that  tools  and  methodologies  are  becoming  a 
problem  in  themselves. 

One  respondent  (MH)  felt  so  many  alternatives  were  available 
that  the  task  of  evaluating  them  was  a  primary  problem  and 
actually  stood  in  the  way  of  making  any  progress.  The  impor- 
tance of  deciding  to  do  something  was  stressed.  (This  concern 
tends  to  support  an  INPUT  conclusion  from  earlier  research  that 
many  EDP  managers  are  confused  as  to  what  should  be  done 
about  productivity  and  consequently  do  nothing.) 

Another  respondent  (NS)  felt  that  structured  environments  and 
methodologies  discouraged  good  personnel  and  frequently  caused 
them  to  seek  other  employment.  His  feeling  was  that  the  pos- 
sible benefit  to  the  less  qualified  employees  did  not  warrant  the 
impact  on  the  high  performers. 

One  respondent  stated  that  personnel  was  not  the  problem.  The  bottle- 
neck, as  he  saw  it,  was  analysis  and  design,  and  the  implication  was 
that  the  problem  could  be  solved  with  program  direction  and  tools. 

•  Respondents  were  also  asked  how  serious  the  productivity  problem  was  in  the 
EDP  industry  and  in  their  company.  In  addition,  they  were  asked  what  would 
happen  if  it  did  not  improve.  The  views  expressed  by  the  various  respondents 
are  as  follows: 

CSE  stated  that  on  a  scale  of  one  to  10  (with  one  being  most  serious) 
the  problem  in  the  industry  would  be  a  "I,"  and  the  problem  in  the 
company  was  a  "three  to  four."  They  felt  that  the  result  would  be  a 
transfer  of  functions  to  users,  and  that  this  was  good. 
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MH  felt  that  productivity  was  "going  backward"  in  the  industry.  As  far 
as  the  company  was  concerned:  "we  are  doing  our  thing  -  something  is 
going  to  get  done."  The  conslusion  was  reached  that  unless  things 
improved,  there  would  be  "decentralization,  lack  of  control,  and  more 
expense." 

Singer  felt  things  in  the  industry  were  "very  bad"  because  of  lack  of 
talent  and  increasing  complexities  in  the  industry.  The  respondent 
stated  that  things  were  "even  worse"  in  the  company.  -  However,  he 
expressed  hope  that  new  tools  and  techniques  would  salvage  the  situa- 
tion. Specifically,  he  stated  programmers  could  not  be  depended  upon 
to  solve  the  problem;  it  would  be  necessary  for  users  to  develop  their 
own  systems. 

CIC  expressed  the  feeling  that  the  problem  was  serious  in  both  the 
industry  and  the  company  and  concluded  that  more  responsibilities 
would  go  to  the  users. 

C&S  compared  the  current  problems  in  commercial  systems  (banking) 
with  those  in  the  aerospace  industry  in  the  late  1950s.  He  stated  the 
space  effort  would  not  have  succeeded  if  engineers,  scientists,  and 
technicians  had  been  forced  to  rely  on  programmers  to  solve  their 
problems.  There  was  an  "explosion"  in  end  user  development  which 
resulted  in  only  6%  of  the  programming  being  done  by  the  data  process- 
ing development  function  and  the  rest  by  users.  He  looks  for  a  similar 
"explosion"  among  commercial  users  because  the  need  is  so  great  and 
because  tools  are  becoming  available. 

UNC  felt  their  problem  was  worse  than  that  of  the  industry  because  of 
low  pay  scales  and  lack  of  program  motivation  among  systems  person- 
nel. They  felt  that  productivity  was  improving  but  demands  were 
also.  No  answer  was  given  as  to  what  would  happen,  but  the  implica- 
tion was  that  things  would  continue  as  they  currently  are. 
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The  NS  representative  felt  that  the  productivity  problem  was  serious 
enough  to  bother  everyone,  including  his  company.  The  result  would  be 
that  users  would  become  more  involved  in  solving  their  own  problems. 
He  was  not  sure  whether  this  would  help  or  not  -  it  might  prove  more 
costly  but  lower  the  level  of  discontent. 

in  an  attempt  to  determine  the  focus  of  the  productivity  problem,  respondents 
were  asked  to  rank  the  relative  importance  of  various  phases  of  the  systems 
life  cycle  and  also  to  identify  the  most  critical  general  aspects  of  the  prob- 
lem. The  results  are  shown  in  Exhibit  IV-7. 

it  is  readily  apparent  that  the  respondents  felt  the  systems  life  cycle 
broke  down  into  two  distinct  parts  in  terms  of  importance.  Problem 
definition,  analysis,  and  design  are  all  considered  to  be  the  primary 
problem  areas,  whereas  programming,  testing,  maintenance,  and 
enhancement  are  all  considered  to  be  of  substantially  less  importance. 
Two  respondents  identified  only  the  most  important  phase,  and  they 
picked  design.  However,  it  is  assumed  good  design  is  dependent  upon 
both  problem  definitions  and  analysis.  The  general  conclusion  is  that  if 
you  don't  know  what  you  are  doing  before  you  start  programming  there 
are  bound  to  be  problems  later.  Some  of  the  comments  on  the  life 
cycle  are  as  follows: 

The  time  and  expense  of  maintenance  and  enhancements  are 
"symptoms  caused  by  design  problems." 

"Structured  methodologies  may  be  causing  the  problem. 
Managers  are  afraid  to  start  programming  late  in  structured 
programming  which  means  that  analysis  and  design  are  im- 
pacted." 

Programming  is  "not  the  problem." 
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EXHIBIT  IV-7 

THE  FOCUS  OF  THE  PRODUCTIVITY  PROBLEM* 
EDP  DEPARTMENT  RESPONDENTS 


CSE 

SINGER 

CIC 

MH 

C&S 

UNC 

NS 

MEAN 

Life  Cycle 

- 

Problem  Definition 

3 

1 

1 

3 

1 

1.8 

Analysis 

1 

2 

2 

1 

2 

1.5 

Design 

2 

1 

3 

3 

1 

1 

3 

2.0 

Programming 

5 

- 

6 

5 

- 

4 

- 

5.  0 

Testing 

4 

- 

4 

6 

- 

6 

- 

5.0 

Maintenance  S 
c  11  rial  icemen t 

6 

5 

4 

5 

5.  0 

General  Structure 

Broadbased  Management 

2 

1 

1 

2 

1 

1.4 

User  Invoi/ement 

1 

2 

1 

1 

1 

2 

1.3 

Effective  Personnel 

n 

3 

3 

3 

1 

3 

2.8 

Commitment  to  Qualify 

3 

4 

4 

5 

2 

3.  6 

Tools  &  Aids 

5 

5 

5 

4 

4.  75 

*  1  -  Most  Important,  5  =  Least  Important;  therefore  lower  mean  ratings  represent  most  important. 
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Quality  control  (testing  and  shakedown)  is  a  "bad  time  to  find 
problems." 

Maintenance  and  enhancement  are  currently  "a  major  problem 
(or  symptom)  caused  by  the  others." 

"Improve  problem  definition  and  all  of  the  others  will  improve  - 
especially  maintenance." 

"Systems  are  being  designed  without  maintenance  and  enhance- 
ment in  mind.  After  all  these  years,  you  would  think  we  would 
know  better,  but  it  is  still  the  problem." 

"Bug  maintenance  is  improving,  but  enhancements  still  kill  you." 

"Analysis  and  design  are  interdependent  (and  the  most  important 
phases)  and  are  frequently  sacrificed  to  meet  schedules." 

"It  is  not  apparent  that  we  are  either  solving  or  understanding 
some  of  the  business  problems."  (This  comment  qualified 
"problem  definitions"  as  the  most  important  problem.) 

"Prototyping  may  be  a  potential  solution  to  the  life  cycle 
problems,  but  watch  out  for  integrations." 

Concerning  maintenance  and  enhancement:  "This  is  a  fuzzy 
area  and  the  accounting  types  think  they  have  found 
something:  $X  for  development  and  $Y  for  maintenance,  if  $Y 
is  high,  this  is  bad.  This  (logic)  is  highly  questionable,  but  IBM  is 
preaching  this  philosophy.  It  could  result  in  solving  the  wrong 
problems." 
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As  far  as  the  general  structure  of  the  productivity  problem  is  con- 
cerned there  is  general  agreement  that  "user  involvement"  and  "broad- 
based  management"  are  the  primary  areas  which  need  improvement. 
Significantly,  "effective  personnel"  is  only  internal,  and  "tools  and  aids" 
are  the  least  important  area.  Comments  concerning  the  general  struc- 
ture of  the  productivity  problem  were  as  follows: 

Commitment  to  quality  "comes  from  the  first  three"  (broad- 
based  management,  user  involvement,  and  effective  personnel). 
(This  was  stated  by  someone  who  rated  commitment  to  qualities 
fourth.) 

"1  am  not  excited  about  tools  and  aids." 

Someone  who  stated  that  user  involvement  was  the  most  impor- 
tant area  commented:  "politics  are  still  a  problem." 

"Quality  is  not  a  primary  concern;  it  will  follow  the  others.  Just 
saying  you  are  committed  to  quality  doesn't  solve  a  thing." 

"There  is  a  failure  in  Systems  and  Procedures  (S&P)  in  the  way 
they  perceive  problems.  They  think  'cost  justification'  is  the 
problem,  but  it  is  really  operational  costs  which  are  important  in 
terms  of  achieving  quality  results.  The  ability  to  justify  and 
install  electronic  systems  is  not  the  problem,  except  for  ven- 
dors. S&P  has  to  achieve  improvements  based  on  the  objectives 
of  the  particular  company  they  are  working  for  -  this  is  fre- 
quently overlooked." 

"There  is  a  need  to  keep  outstanding  people  involved  in  imple- 
mentation. Too  many  are  lost  to  management." 
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"If  you  don't  have  the  first  two  (broad-based  management  and 
user  involvement)  you  can  have  all  the  'commitment  to  quality' 
and  'tools  and  aids'  you  want  and  nothing  is  going  to  get  done." 

While  there  appears  to  be  general  agreement  on  the  overall  productivity 
problem  and  even  its  focus,  the  comments  of  the  EDP  department  respondents 
showed  substantial  variance  in  perception  and  reaction  to  the  problem.  It  is 
probable  that  general,  published  analysis  and  terminology  solicit  "knee  jerk" 
reactions  and  even  "lemming-like"  actions  from  EDP  management.  However, 
the  individual  observers  of  productivity  do  not  see  the  same  things  when 
viewing  their  particular  organizations.  The  observed  differences  are  of  more 
importance  than  the  surface  similarities. 

SOFTWARE  VENDOR  RESPONDENTS 

The  software  vendors'  reactions  to  the  general  productivity  problem  were 
more  specific  than  the  EDP  managers'  and  to  a  certain  degree  are  based  on 
their  solutions.  The  responses  by  company  are  as  follows: 

Mathematica  Products  Group  (MPG)  had  the  following  comments  on 
productivity  and  its  primary  problems  and  bottlenecks: 

"Given  any  set  of  tools,  an  'expert'  can  effect  a  10%  increase  in 
productivity," 

"The  fourth  generation  concept  is  'breakthrough'  and  not  merely 
a  tool."  The  interviewee  drew  a  rough  chart  to  illustrate  his 
point,  as  shown  in  Exhibit  IV-8.  This  chart  will  be  refined  and 
analyzed  later,  but  the  essential  claim  for  the  fourth  generation 
concept  is  clear. 

The  primary  problem  and  bottleneck  was  stated  to  be:  "not 
using  a  fourth  generation  language."  In  other  words,  with  such 
an  obvious  solution,  everyone  should  be  using  it. 
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EXHIBIT  IV-8 


THE  FOURTH  GENERATION  "BREAKTHROUGH" 
(AS  DEPICTED  BY  VENDOR  RESPONDENT) 


A 


System  Size 

Conventional  Systems  Development 
Structured  Methodology 
Fourth  Generation  Systems 
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The  secondary  problem  was  stated  as:  "the  rate  at  which  re- 
quirements change  and  the  time  they  take  to  develop  -  lots  of 
systems  just  never  get  developed."  He  then  stated  that  the  one 
saving  grace  was  that  the  larger  systems  are  more  stable.  (The 
observation  should  be  made  that  the  reason  for  this  may  be  that 
they  can't  be  changed,  and  this  is  a  real  problem.) 

MSA  had  the  following  observations  about  the  general  state  of  produc- 
tivity: , 

,         "Problems  will  get  worse  for  EDP.   In  fact,  the  problem  has  not 
even  been  defined." 

"IBM  has  backed  off  on  productivity  and  will  do  anything  to  get 
things  installed.  Quality  is  now  the  thing  you  hear  so  much 
about  -  error-free  and  process-predictable." 

"Productivity  is  really  a  management  problem  and  varies 
tremendously  with  what  is  being  done,  but  it  is  primarily  people- 
oriented." 

SAS  has  a  more  structural  view  of  the  problem: 

"Everyone  reinvents  the  wheel  over  and  over.  They  build  indi- 
vidual applications  to  solve  individual  problems.  Even  with  a 
true  DBMS  solution,  the  binding  time  for  recompiling  kills  you." 

"Moving  data  around  is  the  primary  problem." 

"People  are  always  working  on  the  wrong  things;  they  cannot 
identify  the  problems  to  be  solved." 
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"The  investment  in  solving  the  problenn  can  be  a  net  liability. 
For  example,  the  processing  of  SMF  in  IBM  systems  is  more 
costly  than  any  savings  which  might  result  from  using  the  infor- 
mation." (The  implication  was  that  solutions  to  the  productivity 
problem  could  actually  be  contributing  to  that  problem.) 

Sundance  tended  to  take  the  view  of  the  potential  EDP  user  in  defining 
the  general  problem. 

"There  are  tremendous  variations  in  individual  ability  based  on 
paper  qualifications.  Users  can't  distinguish  who  is  good  and 
who  is  bad.  They  prefer  to  contract  for  a  system  and  depend 
upon  someone  else  to  assure  personnel  quality." 

Stated  another  way:  "Clients  (low  end  users)  have  no  way  of 
finding  or  keeping  good  personnel." 

"Estimating  and  individual  variations  in  personnel  quality  are  the 
primary  problems  for  the  systems  area  in  general." 

•  In  determining  the  magnitude  of  the  problem  and  what  will  happen  if  things 
don't  improve,  vendors  were  naturally  inclined  to  identify  their  solution  with 
the  problem. 

Mathematica,  while  they  did  not  specifically  answer  the  question, 
seemed  to  have  the  following  attitude: 

There  is  obviously  still  a  problem  in  the  industry. 

in  their  company  they  have  solved  the  problem  by  using  their 
own  product. 
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^  The  fourth  generation  "breakthrough"  wili  improve  things,  so 
there  is  no  need  to  worry  about  what  will  happen. 

SAS  has  taken  a  somewhat  different  point  of  view  from  the  other 
vendors. 

They  feel  the  problem  in  the  industry  is  "severe,"  primarily 
because  people  are  working  on  the  wrong  problem. 

,  •  They  expressed  concern  because  of  the  shortage  of  good  person- 
nel during  a  time  when  they  are  growing.  Their  concern  about 
maintaining  their  own  productivity  level  was  summarized  in  the 
statement,  "You  can't  have  good  productivity  without  good 
people." 

When  asked  what  was  going  to  happen,  the  answer  was:  "Not 
much.  Those  who  think  applications  programmers  are  going  to 
disappear  are  kidding  themselves." 

MSA  was  rather  straightforward  in  their  answers: 

"There  is  so  much  talk  there  must  be  a  problem  out  there." 

"They  think  they  are  pretty  good  by  industry  standards  because 
they  have  'learned  to  manage."' 

In  response  to  what  may  happen,  they  felt  that  "more  econom- 
ical solutions  are  becoming  available  for  many  standard  applica- 
tions and  functions." 

•         In  Identifying  the  focus  of  the  problem,  vendors  were  again  somewhat  inclined 
to  focus  the  problem  in  light  of  their  solution. 
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Mathematica  identified  problem  definitions,  analysis,  design,  and 
programming  as  the  interrelated  (and  presumably  inseparable)  focus  of 
the  productivity  problem. 

it  was  stated  that  fourth  generation  systems  generate  functional 
specifications  which  become  a  draft  user  manual  (which  the  user 
approves),  and  program  specifications  are  eliminated. 

It  was  then  pointed  out  that  fourth  generation^  systems  also 
facilitate  "testing  and  shakedown"  and  "maintenance  and  en- 
hancement." 

•  User  involvement  was  rated  as  being  the  most  important  structural  problem  in 
software  development,  and  "commitment  to  quality"  was  deemed  to  be  next  in 
order  of  importance. 

MSA  viewed  the  problem  of  focus  and  structure  from  the  point  of  view 
of  their  product  development  and  did  not  specifically  rank  the  items 
because  they  felt  that  general  management  was  the  solution.  Their 
comments  were  as  follows: 

"The  problems  exist  where  they  are  ignored.  For  example,  if  we 
turn  out  a  poor  product,  we  pay  for  it  later.  Perhaps,  from  a 
business  point  of  view,  we  have  to  get  a  product  out  the  door 
and  are  willing  to  bear  the  expense  in  maintenance  and  enhance- 
ment. However,  if  we  want  to  minimize  maintenance  and 
enhancement,  we  manage  that  problem  by  phasing  our  incentive 
pay  so  that  the  message  is  clear,  Mf  your  system  has  a  lot  of 
bugs  during  the  first  six  months  your  bonus  is  going  to  suffer.'" 

"Ail  problems  can  be  eliminated  by  good  management."  (MSA's 
general  systems  and  business  management  was  emphasized 
during  the  interview  and  will  be  presented  in  the  case  study.) 
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SAS  has  a  particular  theme  they  are  currently  pursuing  which  came  up 
frequently  during  the  interview  (or  at  least  the  interviewee  had  a 
particular  point  of  view).  That  theme  sums  up  the  systems  develop- 
ment productivity  problem  as  follows: 

"People  are  solving  the  wrong  problems,  and  therefore  problem 
definition  is  not  only  the  primary  problem,  it  is  the  only  prob- 
lem." 

"The  rest  of  the  systems  life  cycle  is  being  mismanaged.  It's 
like  saying  how  you  were  killed  is  important  after  you're  dead. 
Why  distinguish  what  is  worst  when  it  is  the  whole  thing?" 

Broadbased  management  was  considered  the  most  important 
attribute  of  the  problems:  "EDP  management  must  know  the 
business  they  are  in,"  and  effective  personnel  was  considered  to 
be  of  equal  importance  because  it  was  another  aspect  of  broad- 
based  management. 

User  involvement  was  cited  as  the  second  most  important 
attribute. 

Sundance  ranked  the  systems  life  cycle  phases  in  the  following  order  of 
importance:  I)  problem  definition,  2)  analysis,  3)  design,  and  4)  pro- 
gramming. The  statement  was  made  that  the  systems  development 
process  is  a  joint  EDP-user  problem  with  communications  being  the 
most  important  weakness.  Concerning  the  structure  of  the  problem, 
the  following  statements  were  made: 

"User  management  cannot  be  broadbased  at  the  low  end  of  the 
market."  (In  other  words,  they  cannot  be  really  knowledgeable 
of  data  processing.) 
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"By  definition,  (low  end)  users  are  involved.  They  have  decided 
to  buy  a  'systems  solution'  to  a  problem  they  have,  and  they 
don't  do  this  unless  they  are  involved." 

Effective  personnel  was  considered  the  most  critical  factor  (as 
previously  pointed  out). 

"The  main  quality  of  a  system  is  that  it  works." 

Tools  and  aids  were  rated  of  least  importance. 

CONCLUSIONS  ABOUT  SOFTWARE  DEVELOPMENT  PRODUCTIVITY 

There  is  general  agreement  that  problem  definition,  analysis,  and  design  are 
the  primary  phases  of  the  system's  life  cycle  which  require  attention.  How- 
ever, past  INPUT  research  indicates  that  the  definitional  process  consumes 
the  least  amount  of  time  and  effort  on  the  typical  project,  as  shown  in  Exhibit 
IV-9. 

INPUT  concluded  this  was  true  for  the  following  reasons: 
Both  management  and  EDP  want  to  see  results, 
it  is  the  most  difficult  part  of  the  development  process. 
It  is  the  most  impervious  to  mechanization. 

Since  it  is  somewhat  foreign  to  computer  people,  they  give  it  little 
attention  in  an  effort  to  get  to  the  more  comfortable  technical  tasks  as 
soon  as  possible. 
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•  These  conclusions  were  not  original  at  the  time  they  were  made.  For  over  20 
years,  it  has  been  well  known  that  programmers  like  to  start  programming, 
analysts  like  to  start  analyzing,  and  nobody  wants  to  spend  very  much  time 
with  the  end  user  solving  his  problem.  The  fact  that  things  haven't  changed 
very  much  over  the  last  20  years,  as  shown  in  Exhibit  lV-3,  would  seem  to 
indicate  the  following:  . 

The  problem  is  communications.  If  a  successful  system  is  to  be  devel- 
oped, the  users  must  articulate  their  needs,  and  -  the  systems 
analyst/programmers  must  understand  their  needs.  This  seems  simple 
enough,  and  some  respondents  actually  pinpointed  communications  as 
the  fundamental  problem. 

Since  the  problem  has  been  recognized  for  some  time  and  the  solution 
seems  relatively  simple,  why  hasn't  more  progress  been  made  in  getting 
users  and  EDP  people  to  talk  with  each  other?  The  answer  is  relatively 
simple  also: 

They  do  not  respect  each  other.  Users  feel  that  EDP  employees 
do  not  understand  the  business  of  the  company  they  are  working 
for  and  that  they  have  little  loyalty  to  the  company.  EDP 
employees  feel  users  "do  not  know  a  computer  from  a  television 
set"  and  can't  explain  what  they  need. 

They  do  not  like  each  other.  Users  feel  EDP  employees  are 
generally  overpaid  for  what  they  are  doing  and  that  they  are 
condescending  in  discussing  technical  matters.  EDP  employees 
feel  users  expect  too  much  and  are  chronic  complainers  when 
the  least  little  thing  goes  wrong. 

They  do  not  trust  each  other.  Users  feel  EDP  employees  are 
only  interested  in  new  computer  systems  and  that  in  the  past 
they  have  too  often  come  up  with  costly  systems  that  didn't 
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work.  EDP  employees  feei  users  prefer  to  blame  them  for  any 
failure  rather  than  accept  responsibility  for  not  doing  their  own 
jobs  properly. 

People  who  do  not  respect,  like,  or  trust  each  other  do  not 
communicate  very  well.  Even  if  they  superficially  attempt  to 
communicate,  they  do  not  listen  to  or  believe  what  the  other 
person  is  saying.  - 

Despite  all  of  the  surface  awareness  and  activity  to  bring  users  and 
EDP  departments  closer  together,  respondents  sense  that  problems  are 
getting  worse,  and  it  is  probably  for  the  following  reasons: 

Users  are  beginning  to  gain  more  knowledge  of  computer 
systems  and  no  longer  hold  the  EDP  department  in  awe.  In  fact, 
as  the  quality  of  personnel  in  EDP  departments  becomes  sus- 
pect, users  are  actually  becoming  disdainful  of  the  function. 

In  return,  EDP  personnel  have  disdain  for  the  user  who  "thinks 
he  is  a  computer  expert  because  he  knows  VisiCalc."  They  also 
feel  they  are  going  to  get  stuck  with  the  garbage  that  is  being 
developed. 

As  distributed  processing  and  office  automation  thrust  EDP 
employees  out  of  the  computer  room  and  into  the  working 
environment,  both  sides  are  going  to  uncover  the  weaknesses  in 
the  other,  and  based  on  past  experience  this  will  not  lead  to 
better  communications. 

The  general  economic  situation  will  only  exacerbate  the  situa- 
tion. Despite  all  the  arguments  about  how  many  megaflops  a 
dollar  will  buy  today  as  compared  to  ten  years  ago,  today's 
proposed  solutions  are  expensive,  and  there  is  extreme  competi- 
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tion  for  resources.  There  Is  almost  bound  to  be  resentment  on 
one  side  or  the  other  when  personal  computers  or  minicomputers 
are  purchased  at  the  expense  of  a  308 1  or  vice  versa. 


It  is  also  true  that  if  users  get  involved  in  failures  they  can  be 
fired.  Systems  personnel  may  be  also,  but  they  have  a  much 
better  chance  of  finding  another  job.  Two  parties  attempting  to 
shift  responsibilities  from  one  to  the  other  do  not  communicate 
very  well. 

Therefore,  systems  development  productivity  narrows  down  to  a  complex 
problem  in  human  relations  which  will  not  readily  lend  itself  to  technical  or 
engineering  solutions.  Human  relations  problems  are  solved  by  good  manage- 
ment, and  that  cannot  be  engineered  either. 


C.       FACTORS  IN  IMPROVING  SOFTWARE  DEVELOPMENT  PRODUCTIVITY 


PRIOR  INPUT  RESEARCH  . 

If  the  problem  description  above  sounds  convoluted  and  practically  beyond 
analysis,  it  is  due  to  its  very  complexity.  A  great  many  highly  intelligent 
people  on  both  sides  of  the  user-EDP  relationship  have  worked  without  notable 
success  on  how  to  improve  what  is  perceived  as  low  productivity  in  the  soft- 
ware development  process.  In  its  productivity  study,  INPUT  finally  reached 
the  conclusion  that  several  things  were  necessary: 

The  first  thing  which  became  apparent  was  that  most  EDP  departments 
were  in  thrall  -  the  software  productivity  question  was  so  complex  and 
the  multiple  solutions  so  confusing  that  they  simply  were  not  doing 
anything.  The  first  conclusion  was  that  doing  almost  anything  was 
better  than  doing  nothing. 
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The  second  conclusion  was  that  doing  something  might  not  be  very 
effective  unless  some  strategy  was  developed  and  understood. 

The  third  conclusion  was  that  the  convoluted  problem  had  to  be 
straightened  out  so  that  the  components  of  the  strategy  could  be 
identified.  This  was  done  and  resulted  in  the  five  structural  areas 
included  in  this  survey  questionnaire: 

A  commitment  to  quality. 

User  involvement. 

Broadbased  management. 

Effective  personnel.  *  . 

The  right  tools. 

INPUT  also  determined  that  an  effective  strategy  should  be  approached 
in  a  logical  manner,  and  a  "productivity  pyramid"  was  developed,  as 
shown  in  Exhibit  IV- 10.  An  effective  strategy  was  concluded  to  be  one 
that  built  from  the  base  up. 

A  commitment  to  quality  was  established  as  the  foundation  for 
all  else,  with  architectural  stability  being  of  particular  impor- 
tance. 

User  involvement  was  next  emphasized  so  that  users  would 
become:  I)  involved  in  systems  development  and  operation,  2) 
informed  on  what  DP  could  or  could  not  do  for  them,  and  3) 
aware  of  how  their  needs  fit  into  larger  company  requirements. 
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EXHIBIT  IV-10 


THE  PRODUCTIVITY  PYRAMID 
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Broadbased  EDP  management  placed  emphasis  on  the  education 
of  both  top  management  and  users  in  "nontechnical  EDP  funda- 
mentals." (With  our  emphasis  on  two-way  communications,  this 
study  placed  egual  emphasis  on  reciprocal  education  of  EDP 
management.) 

Effective  personnel  emphasized  employee  retention,  motivation, 
and  skills  improvement.  , 

The  right  tools  were  described  as  a  means  of  achieving  "micro- 
productivity,"  but  were  considered  to  be  relatively  useless  in 
achieving  "macroproductivity"  unless  the  other  layers  of  the 
productivity  pyramid  were  in  place. 

•  INPUT  still  endorses  the  conclusions  of  the  productivity  study,  including  the 
productivity  pyramid.  The  relative  importance  of  the  various  components 
indicated  in  the  current  research  indicates  that  there  may  be  a  problem  of 
priorities  among  the  respondents,  as  shown  in  Exhibit  IV-7. 

While  four  of  the  components  were  rated  in  proper  order,  the  founda- 
tion stone,  commitment  to  quality,  was  deemed  to  be  of  only  fourth 
importance.  The  productivity  pyramid  would  be  reconstructed,  as 
shown  in  Exhibit  IV- 1  I. 

While  this  structure  is  more  stable  than  a  pyramid  with  emphasis  on  the 
right  tools,  we  feel  it  has  more  danger  than  is  apparent  from  the 
graphic  representation.  The  dangers  that  we  see  are: 

The  downgrading  of  the  importance  of  commitment  to  quality 
probably  indicates  that  a  real  productivity  strategy  has  not  been 
developed. 
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EXHIBIT  IV-11 


THE  RESTRUCTURED  PRODUCTIVITY  PYRAMID 
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Without  a  significant  commitment  to  quality  (as  defined  by 
INPUT),  concentration  on  user  involvement  is  especially  danger- 
ous since  the  emphasis  on  stability  of  architecture  is  probably 
missing. 

To  many  companies,  user  involvement  leads  to  user  development 
using  either  personal  computers  or  fourth  generation  systems. 
Unless  a  strategy  Is  In  place  which  gives  clear  direction  to  such 
development,  quality  is  bound  to  suffer. 

The  trend  toward  prototyping  without  a  commitment  to  quality 
architecture  can  most  definitely  lead  to  the  problem  expressed 
by  Southern  Railway:  "A  potential  solution  Is  prototyping,  but 
watch  out  for  Integration." 

In  the  EDP  management  rush  to  get  users  Involved,  there  Is  a 
certain  element  of  "let  them  fall  or  let  them  fail;  they  will  have 
to  come  back  to  us  eventually."  Where  this  attitude  exists,  the 
communications  problem  will  only  be  exacerbated. 

EDP  DEPARTMENT  RESPONSES 

The  users'  priorities  for  productivity  improvement  have  been  established 
earlier  in  the  report,  and  their  detailed  approach  will  be  presented  in  the 
Individual  case  studies.  The  current  efforts  to  address  the  areas  Included  In 
the  productivity  pyramid  are  presented  in  Exhibit  IV-I2. 

Commitment  to  quality  is  being  pursued  in  some  fashion  by  five  of  the 
seven  organizations  Interviewed.  However,  there  is  no  real  pattern 
which  can  be  determined.  This  probably  reflects  the  priorities  assigned 
to  this  by  respondents. 
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EDP  DEPARTMENTS' CURRENT  PRODUCTIVITY  INITIATIVES 


COMPANY 
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User  involvement  is  being  pursued  purposefully  by  five  of  the  seven 
respondents  by  joint  project  tecnrts,  and  practically  all  are  at  least 
considering  information  centers.  Two  of  the  respondents  are  pursuing 
somewhat  unusual  end  user  involvement:  Singer  is  in  the  process  of 
going  to  a  decentralized  operation  after  being  highly  decentralized,  and 
C&S  is  currently  in  the  process  of  automating  its  branch  offices 
through  distributed  processing.  End  user  involvement  is  obviously  high 
on  the  priority  list  of  the  respondents. 

Broadbased  management  seems  to  go  hand  in  glove  with  user  Involve- 
ment and,  other  than  UNC,  all  of  the  respondents  are  making  at  least 
some  efforts  in  education  and/or  cross  training. 

Effective  personnel  management  seems  to  receive  only  conventional 
attention  (if  that)  from  three  of  the  organizations  interviewed  (Singer, 
C&S  and  UNC).  However,  some  are  making  preliminary  attempts  at 
skills  analysis  and  cross  training  at  the  working  level. 

Tools  and  aids  are  being  continually  evaluated  to  some  degree  in  all  of 
the  organizations  interviewed,  and  all  are  conscious  that  this  is  becom- 
ing a  necessary,  if  burdensome,  function.  The  continuing  search  would 
indicate  that  the  companies  feel  they  can  improve  and  that  they  are 
being  offered  a  rich,  if  confusing,  array  of  tools  and  aids. 

•         Respondents  were  also  asked  what  would  be  of  most  benefit  to  them  in  pursu- 
ing productivity  improvement.  The  answers  were  as  follows: 

"More  emphasis  on  user  friendly  languages." 

"Don't  know.  It  is  like  beating  an  elephant;  you  have  to  do  it  one  piece 
at  a  time." 

-     -         "A  good,  short  management  course  in  systems  productivity." 
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"More  time  to  analyze  and  evaluate  what  is  already  out  there." 

"A  commercially  available  financial  transaction  processing  system" 
which  would  replace  in-house  development. 

"Make  it  easier  for  the  programmer/analyst  to  deal  with  the  problem 
and  not  the  system."  (IBM  hardware/software  systems  and  also  mmi- 
computers  of  other  vendors.) 

The  software  vendors  interviewed  naturally  did  not  fit  into  the  productivity 
pyramid  in  the  same  way  that  commercial  users  did.  For  example,  user 
involvement  only  occurs  at  the  market  research  level;  commitment  to  quality 
is  necessary  to  stay  in  business;  and  management  is  assumed  to  understand  the 
importance  and  problems  of  systems  development.  However,  in  this  environ- 
ment two  things  become  apparent: 

Special  emphasis  is  placed  on  highly  qualified  personnel,  and  special 
emphasis  on  selection,  training,  retention,  incentives,  and  fringe  bene- 
fits is  apparent  with  all  of  the  vendors  interviewed. 

No  vendor  interviewed  attempted  to  "engineer"  software  development 
by  any  standard  means.  It  was  normally  left  to  the  project  leader  to 
select  the  tools,  aids  and  methodologies  as  he  saw  fit  (although  it  is 
hoped  he  would  share  them  with  others).  Attempts  to  change  this  will 
be  described  in  the  case  studies. 

The  vendor  replies  concerning  developments  which  would  be  of  the  most 
benefit  to  them  in  improving  productivity  were  also  quite  different  from  those 
of  users.  The  "wish  list"  was  as  follows: 

"Something  to  help  with  functional  requirements,  including  documenta- 
tion." 
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"Something  electric  must  happen:  there  must  be  an  understanding  thati 
5%  of  the  people  do  95%  of  the  work."   (While  this  answer  may  seem 
obtuse  it  does  have  some  profundity:  it  implies  that  a  measure  of  true; 
productivity  would  be  valuable.) 

"Standardize  operating  systems,  that's  where  the  complexity  is  for  usi 
and  for  IBM  customers."  ~ 

"Define  productivity  -  nobody  knows  what  it  is.  What  are  the  metrics?" 

"Communications  between  users  and  EDP  need  to  be  sharpened.  A 
good  training  course  might  help,  but  specific  approaches  and  method- 
ologies are  only  confusing  the  issue  at  present." 

"From  the  user  point  of  view,  data  is  the  problem.  A  good  relational 
system  would  be  of  enormous  help,  and  there  is  no  intrusive  reason  it 
should  be  less  efficient  than  other  data  base  systems." 

D.       MEASUREMENT  PROCESSES  AND  METHODS 

•  As  indicated  by  several  vendor  respondents  in  the  previous  section,  one  of  the 
most  beneficial  things  in  pursuing  improved  productivity  would  be  a  clear, 
accepted  definition  and  measure  of  productivity  in  the  software  development 
process.  Such  an  accepted  measurement  does  not  exist  at  this  time,  and  as 
INPUT  pointed  out  in  its  productivity  study,  the  measurement  dilemma  goes 
even  deeper. 

The  first  dilemma,  as  shown  in  Exhibit  IV- 1 3,  is  what  to  count.  Should 
it  be  pages,  lines,  or  bytes? 
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EXHIBIT  IV-13 


THE  MEASUREMENT  DILEMMA:     PAGES,   LINES,  BYTES 
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Even  if  there  is  theoretical  agreement  on  what  is  being  counted, 
definitions  can  vary  by  a  factor  of  2:1  or  more. 


Performance  by  individuals  will  vary  by  at  least  9:1,  and  then 
there  can  be  arguments  about  which  individual  is  actually  being 
most  productive  and  whether  a  large  program  is  better  than  a 
small  program. 

The  second  dilemma  involves  the  important  maintenance- environment, 
and  here  there  are  even  more  alternatives  on  what  should  be  counted, 
as  shown  in  Exhibit  IV- 1 4. 

Here  many  different  languages  are  involved,  and  maintenance 
programmers  are  required  to  deal  with  all  of  the  complexity  of 
the  operating  environment.  Should  only  changes  or  deletions  be 
counted,  or  are  deletions  equally  important?  Should  the  same 
change,  made  in  many  places,  be  counted  only  once  or  each  time 
it  is  made? 

When  considering  bug  maintenance,  productivity  is  virtually 
impossible  to  measure.  On  a  specific  bug,  one  programmer  may 
find  it  in  five  minutes  while  another  may  take  days  (or  never 
find  it).  ./ 

•  Recognizing  the  problems  associated  with  hard  measurements,  it  is  not  sur- 
prising that  most  EDP  managers  adopt  only  the  most  general  measurements. 
Exhibit  IV- 1 5  presents  the  results  of  prior  INPUT  research  on  the  measure- 
ments currently  being  used. 

Approximately  three-fourths  of  the  responding  EDP  managers  stated 
they  tracked  tasks  completed  on  time  as  their  primary  productivity 
measure. 
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EXHIBIT  IV-14 


THE  MEASUREMENT  DILEMMA:  MAINTENANCE 
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EXHIBIT  IV-15 

PRIMARY  MEASURES  OF  SOFTWARE  DEVELOPMENT  PRODUCTIVITY, 

AS  REPORTED  BY  EDP  MANAGERS 
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Expenditures  versus  budgets  was  mentioned  by  about  one-half  of  the 
respondents,  and  one-fifth  stated  they  didn't  bother  to  measure  at  all. 

•  The  on-site  interviews  for  this  study  indicate  that  most  companies  still  rely  on 
project  schedules  and  budgets  as  the  primary  means  of  measuring  productiv- 
ity, as  shown  in  Exhibit  iV-16.  However,  there  are  some  significant  efforts 
underway  to  refine  schedules  (and  budgets)  so  that  they  are  more  meaningful 
estimates  and  measures  of  productivity. 

SCE  does  estimating  and  measurements  based  on  delivered  functions 
and  have  collected  considerable  data  on  past  performance.  (While  they 
have  not  yet  really  analyzed  these  data,  they  "plan  to,") 

C  &  S  is  actually  trying  to  develop  "manufacturing  and  operating  cost 
figures"  which  will  give  a  measure  of  cost  effectiveness  when  com- 
pared with  previous  systems  employed.  Essentially  this  would  deter- 
mine the  value  of  the  electronic  system  versus  the  paper-based  system 
and,  therefore,  would  provide  a  measure  of  the  productivity  of  the 
systems  function  in  delivering  value  to  the  company. 

MPG  believes  in  breaking  down  systems  into  program  modules  which 
average  two  days  of  effort  and  never  exceed  that.  These  modules  are 
carefully  tracked,  and  prompt  feedback  is  available  to  management  for 
estimating  effort  and  measuring  productivity. 

MSA  has  a  comprehensive  systems  planning  and  management  philosophy 
and  process  which  will  be  outlined  in  their  case  study.  As  part  of  this 
process,  incentives  are  scheduled  for  each  project.  Therefore,  the 
incentives  paid  are  a  measure  of  productivity  (or  at  least  the  quality  of 
the  planning  process).  If  incentive  payments  are  high,  it  can  be  con- 
cluded that  productivity  was  high  based  on  the  standards  established 
during  project  planning.  Assuming  the  standards  represenfed  company 
objectives,  productivity  would  represent  helping  the  company  meet  its 
objectives. 
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EXHIBIT  lV-16 
PRODUCTIVITY  MEASUREMENTS  EMPLOYED 


PRIMARY  PRODUCTIVITY  MEASUREMENTS 
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Incentive  payments  provide  a  measure.   (This  implies 
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tives are  properly  established.) 
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• 

Meeting  schedules  and  budgets. 
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Recognizing  the  difficulty  of  the  measurement  problem,  INPUT  has  rated 
various  software  implementation  measurements  on  the  desirability  of  their 
characteristics  and  on  their  applicability,  as  shown  in  Exhibit  IV- 1 7.  Depend- 
ing upon  the  particular  requirements  of  individual  organizations,  appropriate 
measures  can  be  selected  and  refined. 

While  it  is  not  intended  to  imply  that  specific  measurements  are  superior  in 
all  cases,  rankings  from  Exhibit  IV-17  can  be  used  to  derive  total  scores  for 
the  particular  measurements  which  were  evaluated.  This  was  done  on  the 
basis  of  awarding  I  for  high,  2  for  medium,  and  3  for  low. 

Exhibit  IV-17  shows  that  users  are  using  measures  which  generally  rate 
rather  high  on  the  basis  of  our  rankings. 

Tasks  completed  on  time  (B)  and  expenditures  versus  budget  (C) 
both  have  good  characteristics  and  demonstrate  acceptable 
applicability. 

On  the  other  hand,  lines  of  code  (D)  does  not  have  good  charac- 
teristics and  demonstrates  little  applicability. 

Measurements  are  desirable  in  order  to  improve  the  software  development 
process.  When  measurements  are  employed  as  a  management  tool  with  an 
understanding  of  their  underlying  strengths  and  weaknesses,  they  can  assist  in: 

Estimating  the  development  process. 

Predicting  resource  requirements. 

Identifying  problems  in  methodology  or  design. 
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Difficulties  arise  when  raw  measurements  are  input  into  models  and  algor- 
ithms of  the  type  frequently  associated  with  software  engineering  and  then 
become  accepted  as  solutions  to  specific  management  problems.  While 
arranging  an  interview  at  the  University  of  North  Carolina,  INPUT  talked  with 
Dr.  Frederick  P.  Brooks,  Jr.  with  the  following  results: 

He  recommended  Barry  W.  Boehm's  book,  Software  Engineering 
Economics,  as  a  must  for  anyone  concerned  with  the  productivity 
problem.  He  stated  further  that  the  book  had  algorithms  to  facilitate 
project  estimating  and  productivity  measurement  and  that  it  would 
remain  a  standard  reference  work  for  the  next  25  years. 

Mr.  Boehm's  book  was  reviewed  and  found  to  be  a  thoughtful  and  well 
conceived  text  for  college  students,  professors,  and  software 
engineers.  However,  Mr.  Boehm  was  careful  throughout  the  text  to 
qualify  his  algorithms  and  give  emphasis  to  individual  capabilities  of 
both  project  managers  and  project  team  members.  For  example: 

The  basic  model  for  estimating  effort  produced  results  "within  a 
factor  of  1.3  of  the  actuals  only  29%  of  the  time,  and  within  a 
factor  of  2  of  the  actuals  only  60%  of  the  time." 

The  intermediate  model  estimates  are  "within  20%  of  the 
project  actuals  68%  of  the  time." 

In  establishing  productivity  ranges  of  the  cost  drivers  for  the 
model,  personnel/team  capability  has  a  range  of  1-4.18,  the  next 
highest  range  is  1-2.36  for  product  complexity,  and  they  go  down 
to  language  experience  where  the  range  is  1-1.2,  However, 
Boehm  points  out  that  there  is  tremendous  range  in  individual 
differences  (he  quotes  up  to  26-1)  and  stresses  that  using  better 
and  fewer  people  is  the  most  effective  means  of  achieving 
results. 


-  109  - 


Boehm's  book  is  very  useful.  He  has  made  a  substantial  contribution  in 
bringing  together  a  useful  set  of  techniques  and  decision  guidelines 
which  should  be  of  benefit  in  project  management. 

•  However,  the  implication  that  software  can  be  engineered  using  a  set  of 
algorithms  is  dangerous  when  arbitrarily  applied.  Specifically,  it  is  doubtful 
that  current  software  engineering  techniques  would  have  permitted  Dr.  Brooks 
to  either  make  schedules  or  significantly  improve  productivity  on  the  OS./360 
project.  This  is  true  for  the  following  reasons: 

Research  conducted  among  project  leaders  working  on  OS/360  indi- 
cated that  they  could  not  agree  what  constituted  a  difficult  program- 
ming task  and  what  constituted  a  simple  programming  task  (much  less 
who  was  a  good  programmer). 

Programmers  spend  only  13%  of  their  time  writing  programs  and 
approximately  35%  of  their  time  communicating  on  "normal"  systems. 
On  OS/360  at  one  point,  an  independent  survey  could  scarcely  identify 
any  programming  being  done  during  normal  working  hours.  The 
comment  of  the  independent  consultant  was,  "The  bad  part  is  they 
think  they  are  working."  IBM  had  personnel  generally  regarded  to  be  at 
the  high  end  of  the  productivity  range,  but  the  environment  was  not 
conducive  to  producing  anything. 

When  asked  his  project  status,  the  project  leader  responsible  for 
developing  a  COBOL  compiler  stated,  "Not  only  do  I  not  have  anyone 
who  has  ever  implemented  a  COBOL  compiler,  I  do  not  have  anyone  on 
the  team  who  has  ever  written  a  program  in  COBOL." 

Storage  constraint  is  one  of  the  cost  drivers  in  Boehm's  productivity 
model  (range  I -1. 5 1).  OS/360  was  originally  specified  to  run  on  a  I6K 
machine  (a  competitive  ploy  against  an  internal  group  which  was 
developing  DOS). 
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The  list  is  practically  endless,  but  the  message  is  clear:  there  are 
many  factors  impacting  productivity  on  any  given  project  which  cannot 
be  adequately  accounted  for  in  even  the  most  sophisticated  algorithms. 

•  Nevertheless,  Boehm's  work  has  great  merit  in  that  it  identifies  software  cost 
drivers  which  are  of  significance  and  even  puts  them  in  general  perspective. 
For  example,  many  DP  managers  currently  give  high  priority  to  language 
experience  in  recruitment,  and  the  model  points  out  the  low  relative  impor- 
tance of  this  factor.  The  need  for  additional  research  (measurements)  on 
specific  factors,  such  as  personnel  capability,  is  apparent  in  the  model,  but 
generally  it  represents  a  significant  step  in  integrating  a  number  of  complex 
cost  variables. 

•  The  difficulty  with  the  model,  and  with  most  efforts  in  software  engineering, 
is  that  it  addresses  the  problems  associated  with  design  and  implementation  of 
large  complex  projects  such  as  those  in  the  aerospace  industry  (where  most  of 
the  work  originated).  The  problems  associated  with  determining  user  require- 
ments have  not  normally  been  addressed. 

Most  large  projects  such  as  Mercury,  Gemini,  Apollo-Sky  lab,  and  the 
Space  Shuttle  have  the  advantage  of  a  fairly  clear  overall  objective. 
Even  the  original  development  objectives  of  OS/360  were  generally 
clear;  the  difficulty  was  with  the  alternatives  available  to  achieve 
success.  For  example,  if  a  I6K  machine  could  not  be  supported,  the 
entire  mission  did  not  have  to  be  aborted,  or  if  a  particular  function 
could  not  be  delivered,  the  product  could  still  be  released. 

The  problems  with  many  commercial  systems  is  not  only  that  the 
hardware/software  systems  alternatives  are  not  infinite,  but  the 
general  objectives  of  the  system  may  not  be  clear  to  either  the  re- 
questor or  the  implementor.  To  state  that  this  adds  another  level  of 
complexity  to  an  already  difficult  problem  is  to  understate  the  case 
substantially. 
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In  addition,  the  mere  size  of  large  projects  improves  the  probability  of 
success  of  the  model  by  improving  the  probabilities  associated  with  the 
individual  variables.  As  we  all  know,  however,  the  increased  size  of 
the  project  complicates  communications  which  affects  productivity. 
(These  problems  also  increase  with  structured  methodologies.) 

The  problems  of  interfacing  and  communications  are  among  the  most 
complicated  to  measure  and  predict,  and  this  is  acknowledged  by 
Boehm. 

•  It  is  felt  that  the  communications  problems  associated  with  interfacing  on 
large  projects  were  probably  similar  to  those  between  users  and  analysts/pro- 
grammers on  smaller  commercial  systems  as  well  as  the  problems  associated 
with  office  automation.  These  potential  similarities  lead  to  an  intuitive 
conclusion  that  some  of  the  work  being  done  on  queuing  networks  could  have 
application  to  this  problem  While  a  thorough  investigation  of  this  subject  was 
completely  outside  the  scope  of  this  study,  the  opportunity  for  some  inde- 
pendent investigation  presented  itself,  and  a  brief  summary  of  the  results 
follows: 

Queuing  network  theory  arose  out  of  a  combination  of  operations 
research  and  industrial  engineering.  At  present,  there  are  approxi- 
mately 50  people  pursuing  the  subject  worldwide.  One  of  them  is  Dr. 
Ralph  L.  Disney  of  Virginia  Polytechnic  Institute,  and  it  was  with  him 
that  problem  was  discussed. 

Dr.  Disney  revealed  that  there  was  potential  for  application  of  queuing 
network  theory  but  that  a  disciplinary  communications  problem  has 
slowed  work. 

The  theory  has  been  pushed  beyond  the  limits  of  applied  mathe- 
matics, and  it  has  been  difficult  to  get  mathematicians  inter- 
ested in  the  subject. 
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While  interest  has  been  generated  during  the  past  few  years  and 
some  results  may  be  seen  in  the  near  future,  those  results  will 
then  have  to  be  interpreted  for  application  to  industrial 
engineering  and  operations  research  problems. 

Computer  scientists  have  been  less  than  enthusiastic  in  the  past,  but 
recently  there  has  been  a  noticeable  change  probably  because  of  in- 
creased interest  in  local  area  networks. 

The  discussion  concerning  the  applicability  of  queuing  network  models 
to  communications  problems  associated  with  the  systems  development 
process  were  probably  the  first  ever  held.  It  is  concluded  that  refine- 
ment of  current  software  engineering  models  may  eventually  make  it 
either  desirable  (or  necessary)  to  become  acquainted  with  some  of  the 
more  advanced  work  associated  with  operations  research. 


E.       ALTERNATIVES  FOR  SYSTEMS  IMPLEMENTATION 


I .        INTERNAL  DEVELOPMENT 

•  Thus  far  this  report  has  concerned  itself  with  the  problems  associated  with 
software  development  productivity.  The  following  may  be  concluded  concern- 
ing those  problems: 

The  productivity  problem  has  not  been  clearly  defined  by  either  users 
or  vendors. 

The  primary  problems  are  associated  with  the  most  nebulous  factors, 
such  as  personnel  quality,  management,  motivation,  interpersonal 
relations,  and  communications,  which  do  not  lend  themselves  to  engi- 
neering solutions. 
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The  current  solutions  of  methodology  and  tools  address  only  a  small 
part  of  the  productivity  problem. 

There  are  so  many  possible  solutions  to  improving  software  develop- 
ment productivity  that  selection  of  the  right  one  is  becoming  a  part  of 
the  problem  itself. 

Some  of  the  more  advanced  measurement  work  being  done  on  produc- 
tivity is  beginning  to  be  integrated  (most  noticeably  by  Boehm)  into  a 
cohesive  set  of  models  which  have  promise  for  management  use  in 
estimating,  project  control,  and  even  productivity  improvement. 

However,  these  models  are  subject  to  misuse  by  those  seeking  a 
panacea. 

Improved  analysis  and  refinement  of  the  cost  drivers  associated 
with  the  models  will  eventually  require  assistance  from  disci- 
plines outside  computer  services. 


•  There  is  no  indication  that  the  problems  associated  with  internal  development 
of  software  systems  are  going  to  be  solved  in  the  foreseeable  future.  In  fact, 
problems  will  probably  increase  due  to  systems  complexity  and  personnel 
shortage. 

In  order  to  even  contain  the  problem,  companies  need  to  have  produc- 
tivity strategies,  and  few  have  adopted  them. 

There  seems  to  be  a  current  trend  to  accept  certain  approaches,  such 
as  end  user  Involvement,  without  the  underlying  foundation  of  a 
commitment  to  quality. 
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Without  a  properly  ordered  strategy,  even  such  promising  developments 
as  information  centers  and  prototyping  can  lead  to  great  problems  in 
the  future. 

There  is  every  indication  that  as  computer/communications  technology  is 
extended  to  more  complex  problems  and  to  smaller  enterprises  the  internal 
development  of  systems  will  be  not  only  difficult  but  impossible.  Fortunately, 
there  are  alternatives  to  internal  development  of  all  the  software  systems  an 
organization  needs. 

PACKAGE  PURCHASE 

The  alternative  of  purchasing  applications  software  packages  has  been  avail- 
able for  quite  a  few  years.  Despite  a  cost  advantage  of  approximately  1:10  in 
favor  of  the  purchase  price  of  an  application  package  versus  in-house  develop- 
ment of  a  comparable  package,  many  companies  have  resisted  buying  them. 
The  reasons  for  this  were:  ; 

Conflicting  cost  comparisons  caused  by  poor  estimates  of  internal 
development  costs  and  the  projected  costs  of  modifying  packages  for 
installation. 

The  customer's  feeling  of  uniqueness  and  the  EDP  department's  sus- 
picion of  any  foreign  product. 

Concerns  about  the  stability  of  the  software  vendor  including  the 
ability  to  support  and  maintain  the  product. 

This  resistance  to  the  purchase  of  packaged  applications  software  is  breaking 
down  because  of: 

Management  pressures  on  the  EDP  department  for  more  productivity 
(cost  effectiveness). 


Clearer  cost  justification  based  on  more  realistic  estimates  of  the  cost 
of  internal  development. 

Better  design  of  applications  packages  to  facilitate  modification  and 
tailoring  and  more  clearly  serve  the  needs  of  the  customer. 

The  growth,  stability,  and  service  provided  by  some  vendors  has  allayed 
fears  of  unsupported  products.  (MSA  at  $100  million-  in  sales  and 
profits  is  more  sound  than  most  of  its  customers.) 

The  personal  computer  explosion  has  created  two  separate  markets, 
one  for  hardware  and  one  for  software,  and  the  concept  that  you  shop 
for  both.  This  has  changed  the  attitudes  of  many  business  customers, 
especially  at  the  low  end  of  the  market. 

The  rather  sudden  acceptance  of  packaged  applications  as  an  alternative  to 
internal  development  became  apparent  when  INPUT  forecast  growth  of  26%  in 
sale  of  packages  from  1980  to  1981,  and  the  actual  increase  was  56%. 

Even  so,  the  attitude  of  the  EDP  departments  interviewed  in  this  study  was 
surprising  in  its  support  of  packaged  applications  packages. 

"Make  versus  buy"  decisions  are  routinely  made  during  project  planning 
by  all  of  the  companies  interviewed,  and  users  are  involved  in  those 
decisions. 

At  CIC,  a  special  task  force  has  been  established  to  review  the  possible 
purchase  of  a  Policy  Management  System  (PMS).  This  would  represent 
a  substantial  investment,  but  also  an  enormous  savings  in  human  re- 
sources. 
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UNC  stated  that  packages  (from  outside  vendors)  were  being  ennpiia- 
sized  by  IBM  for  the  4341.  While  the  respondent  felt  this  was  being 
done  to  justify  the  hardware  cost,  the  customer  was  receptive  and 
IBM's  strategy  seems  clear. 

C  &  S  went  so  far  as  to  state  the  most  promising  things  they  saw 
affecting  productivity  in  the  EDP  industry  was  the  elimination  of  EDP 
development  activities  through  end  user  development  and  the  purchase 
of  packages.  (They  are  currently  considering  a  transaction-oriented 
financial  system  for  their  branches.) 

The  specific  instances  cited  above  could  not  have  occurred  three  to  four  years 
ago  because:  I)  quality  packages  were  not  readily  available,  2)  the  attitudes 
of  major  customers  (such  as  banks  and  insurance  companies)  were  oriented 
toward  internal  development,  and  3)  IBM  would  never  have  encouraged  use  of 
an  outside  vendor  for  anything. 

END  USER  DEVELOPMENT 

This  alternative  was  covered  earlier  in  the  report  because  it  is  a  major  trend 
in  the  industry.  The  support  given  to  end  user  development  by  respondent 
EDP  departments  is  striking. 

SCE  stated:  "The  Computer  User  Services  department  demonstrates 
our  commitment.  It  (involvement)  is  not  a  part-time  thing  for  users." 

CIC  has  a  stated  corporate  policy  that  end  users  will  become  involved 
in  systems  development,  and  this  has  been  translated  into  the  highest 
priority  objective  for  the  EDP  function. 

At  Singer,  the  users  are  being  involved  by  the  complete  decentraliza- 
tion of  systems  responsible,  including  hardware.  In  a  particular  divi- 
sion, the  Director  of  Operations  is  assisting  users  with  their  own 
development  because  the  MIS  function  is  somewhat  recalcitrant. 


-  MH  has  established  joint  systems  development  functions  (Business 
Systems  Development)  and  also  an  information  center  under  Decision 
Support  Systems. 

C  &  S  feels  that  end  user  development  is  one  means  (along  with  pack- 
ages) of  eliminating  EDP  development  activities  altogether, 

UNC  has  a  systems  and  procedures  organization  whicK  is  under  the 
joint  control  of  Administrative  Data  Processing  (EDP)  and  end  users. 

At  Southern  Railway  they  are  attempting  to  get  users  involved  on  a 
project-by-project  basis,  and  the  Assistant  Vice  President  of  MIS  wants 
to  keep  them  involved  through  the  entire  implementation  process. 

•  While  there  can  be  no  question  about  the  trend  of  getting  end  users  involved, 
and  while  it  is  assumed  most  EDP  departments  are  sincere  in  their  efforts, 
there  are  some  possible  negative  aspects  of  the  trend,  its  causes,  and  its 
effects, 

-  Many  people  feel  that  personal  computers  had  a  lot  to  do  with  this 
sudden  interest  in  getting  users  involved  and  that  involvement  is  a 
means  toward  EDP  control. 

Some  cynics  (or  realists)  state  that  the  EDP  department,  vendors  and, 
in  some  cases,  users  are  in  collusion  to  hide  the  true  costs  of  systems 
development  from  top  management.  It  certainly  should  help  control 
the  budgets  of  the  EDP  department. 

There  are  indications  that  some  EDP  managers  are  letting  end  users 
become  involved  in  development  to  cut  down  the  noise  level  temporar- 
ily while  they  wait  for  the  users  to  fail. 
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At  least  one  consultant  has  stated  that  the  drive  toward  information 
centers  is  wonderful:  "In  two  or  three  years  there  will  be  more 
consulting  work  trying  to  straighten  out  the  information  center  mess 
than  anyone  can  handle." 

Most  serious  analysts  of  the  trend  toward  user  development  frankly  admit 
they  do  not  know  what  the  costs  and  technical  problems  will  be.  But  the  trend 
is  real,  and  there  is  every  indication  it  will  continue.  ~~ 

PURCHASE  OF  SERVICES 

The  user  EDP  departments  interviewed  were  not  terribly  enthusiastic  about 
the  purchase  of  outside  services  for  software  development  by  either  personal 
service  contract  or  by  project.  The  primary  reason  was  unquestionably  the 
size  of  the  companies  interviewed  and  the  fact  that  EDP  departments  gener- 
ally regard  purchase  of  outside  services  as  a  temporary  expedient.  Reasons 
for  this  resistance  parallel  those  for  packaged  programs. 

The  cost  of  contract  programmers  may  appear  high  due  to  failure  to 
account  for  all  expenses  of  full-time  employees,  and  the  contract  price 
for  a  project  usually  appears  high  compared  to  internal  estimates. 

While  EDP  departments  normally  do  not  mind  adding  contract  program- 
mers to  projects,  they  do  have  an  inherent  dislike  of  project  contracts 
because  of  legitimate  concerns  about  quality  and  irrational  concerns 
about  exposing  their  own  weaknesses  to  management  and  users. 

There  are  also  the  concerns  of  support  and  maintenance  because 
project  teams  (or  individuals)  are  inherently  unstable  in  the  sense  that 
it  is  unlikely  the  specific  implementation  will  be  available  to  solve 
problems. 
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The  situation  with  smaller  companies  and  first-time  users  is  the  reverse. 
Management  in  small  organizations  is  inclined  to  be  more  concerned  about 
full-time  data  processing  employees  than  they  are  about  contracting  for 
services.  The  situation  was  well  analyzed  by  Sundance. 

The  first-time  computer  user  has  a  frame  of  reference  which  prompts 
him  to  buy  what  he  needs.  Before  contracting  for  hardware  he  has 
determined  what  he  wants  to  do  and  how  much  he  will  pay.  Buying  a 
system  for  a  fixed  amount  appeals  to  him.  - 

In  addition,  he  thinks  it  is  unnecessary  to  hire  full-time  systems  people 
because  there  would  be  nothing  for  them  to  do  once  his  system  is 
installed. 

Even  if  he  wanted  to  hire  a  systems  analyst  or  programmer,  he  has  no 
way  to  determine  the  qualifications  which  are  required.  And  experi- 
enced data  processing  personnel  present  a  problem  because: 

They  normally  don't  want  to  work  for  small  companies  because 
of  obvious  restrictions  on  advancement. 

Their  salary  requirements  may  be  higher  than  those  of  senior 
executives  in  the  company. 

In  addition,  IBM  is  currently  recommending  specific  systems  houses 
such  as  Sundance  to  its  customers.  This  endorsement  would  have  been 
unthinkable  just  a  few  years  ago  but  is  now  becoming  quite  common. 
While  IBM  bears  no  responsibility  for  any  such  contract,  the  mere 
endorsement  lends  a  certain  credibility  to  even  the  smallest  computer 
services  company. 

At  the  other  extreme,  even  larger  companies  are  being  forced  to  consider 
contracting  for  complex  systems  which  require  specific  talents  they  cannot 
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either  find  or  afford  on  a  full-time  basis.  Computer/communications  networks 
are  an  obvious  example  of  an  area  where  there  is  an  extreme  shortage  of 
qualified  personnel.  In  some  ways  the  problems  of  complex  systems  are 
similar  to  those  faced  by  first-time  users. 

EDP  departments  have  difficulties  selecting  qualified  employees  in 
telecommunications  because  they  do  not  understand  the  requirements. 

There  is  a  feeling  that  once  the  network  is  installed  you  won't  need  a 
lot  of  high-priced  telecommunications  people. 

•  Our  research  also  discloses  an  additional  area  of  purchased  services  with 
potential  for  freeing  internal  resources.  The  evaluation  and  implementation 
of  methodologies  and  tools  are  becoming  an  increasing  burden  for  some  com- 
panies. The  purchase  of  evaluation  and  implementation  services  represents  an 
attractive  alternative. 

5.        OTHER  :      V  .       '         '  ■ 


•  With  complex  systems  there  is  also  another  alternative  to  all  of  the  above, 
and  that  is  the  research  and  development  consortium.  This  permits  the 
sharing  of  scarce  technical  resources  and  implementation  and  operation 
expenses  among  a  group  of  companies  with  common  interests. 

•  One  of  the  first  such  consortiums  was  the  Insurance  Institute  for  Research 
which  was  established  on  a  subscription  basis  by  the  property  and  liability 
insurance  industry.  Its  purpose  is  to  do  research  and  development  on  a  shared 
network  linking  the  various  subscribing  companies  with  their  agents  (both 
company  agents  and  independent  agents).  The  Institute  was  established 
several  years  ago  (its  first  president  is  now  a  principal  of  Sundance),  and  it 
worked  with  the  members  of  the  consortium  on  the  successful  design  of  a 
network  which  could  be  shared  to  accommodate  a  wide  variety  of  installed 
computer  systems  and  terminal  hardware. 
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•  During  the  course  of  this  research  (Electronic  News,  10/11/82),  it  was  an- 
nounced that  IBM  had  "scored  its  first  nnajor  coup  over  AT&T's  American  Bell, 
inc."  by  reaching  an  agreement  with  IIR  to  have  the  IBM  information  Network 
establish  and  operate  the  network.  IBM  was  selected  in  competition  with 
American  Bell's  Advanced  Information  System  (AIS),  Control  Data,  Electronic 
Data  Systems,  National  CSS,  and  Isacomm  (a  subsidiary  of  United  Technol- 
ogies). 

•  Shared  research  and  development  of  complex  systems  among  organizations 
with  common  interests  will  probably  become  fairly  common. 


F.       SOFTWARE  DEVELOPMENT  PRODUCTIVITY  METHODOLOGIES  AND 
TOOLS 


I .       IBM  ANALYSIS  TOOLS  (BSP  &  BICS) 

•  Both  users  and  software  vendors  were  asked  about  their  familiarity  with  IBM's 
Business  Systems  Planning  (BSP)  and  Business  Information  Control  Study 
(BICS).  Most  respondents  were  familiar  with  both  since  they  have  been  well 
publicized,  including  a  comparison  in  the  IBM  Systems  Journal  earlier  this 
year.  Significant  comments  by  respondents  follow. 

"BSP  is  a  good  idea  which  is  impossible  to  implement.  Documentation 
is  the  problem."  (SCE) 

"Don't  get  top  management  involved  in  another  study...."  (SCE) 

"Great  concept,  but  Continental  Is  not  ready  for  something  like  that." 
(CIC) 
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"IBM  is  pitching  enterprise  analysis.  Tremendous  effort  is  involved. 
We  have  put  together  a  planning  methodology  which  has  elements  of 
both  -  it  is  in  six  volumes.  You  have  to  wonder  about  it."  (MH) 

"We  had  a  presentation  and  were  not  impressed,  it  is  a  general  macro 
approach  which  may  have  no  application  in  reality.  It  can  be  viewed  as 
either  too  macro  or  too  micro,  but  it  doesn't  address  any  specific 
situation."  (C  &  S)  ~ 

"Have  had  a  presentation;  we  were  not  enamored  with  them."  (UNC) 

"We  looked  at  BSP,  and  I  am  rather  in  favor  of  treating  the  DP  shop 
like  a  business  and  giving  emphasis  to  information  resource  planning. 
However,  management  thinks  the  environment  changes  faster  than  you 
can  plan  for  it."  (NS) 

"Good  for  people  who  do  not  know  that  two  plus  two  equal  four.  There 
is  nothing  that  isn't  in  a  college  textbook."  (SAS) 

"Good,  if  you  are  the  chief  executive  and  can  afford  to  invest  the  time 
and  money  required.  Questionable  from  a  practical  point  of  view.  It  is 
not  going  to  take  the  industries  by  storm."  (MSA) 

"I  am  very  familiar  with  the  approach;  it  was  applied  when  I  was  with 
IBM  and  worked  with  the  insurance  and  banking  industries.  While  not 
superficial,  it  is  not  really  a  studied  analysis  of  the  problem.  Quite 
frankly,  it  is  as  much  a  sales  tool  as  anything."  (Sundance) 

•  Based  on  these  reactions  it  would  appear  that  BSP  and  BICS  are  closely 
bundled  in  most  people's  thinking,  and  it  would  be  easy  to  conclude  that  prac- 
tical application  of  the  BSP  approach  Is  unlikely  to  have  significant  impact. 
However,  there  is  no  question  that  IBM  is  selling  BSP  and  BICS  hard  to  their 
major  accounts.    It  is  not  advisable  to  ignore  anything  IBM  Is  selling:  there 
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are  too  many  examples  of  success  despite  products  (or  approaches)  which  have 
initially  met  with  poor  reactions  from  customers  and  competitors. 


•  in  October  Computerwor Id  (10/25/82)  gave  considerable  coverage  to  a  BSP 
presentation  which  was  given  by  John  Zachman  (BSP  Consultant  for  the  IBM 
Western  Region  and  also  the  author  of  the  IBM  Systems  Journal  article  on  BSP 
and  BiCS).  While  the  general  presentation  was  a  sales  pitch  for  BSP  and 
stressed  that  "data  design  is  the  key  to  systems,"  there  was  an  Interesting  side 
issue  which  will  be  explored  separately. 

The  question  arose  on  the  connection  between  information  engineering, 
as  defined  by  James  Martin  and  Clive  Finkelstein,  and  BSP.  Zachman's 
reply  was,  "(Martin's  and  Finklesteln's)  hypothesis  that  you  can  derive 
functional  design  from  data  design  is  the  opposite  of  what  traditional 
DP  has  done  -  and  is  a  revolutionary  concept.  While  it  is  still  theory  in 
1982,  my  intuitive  feeling  is  that  information  engineering  is  the  right 
approach." 

In  the  meantime  Martin  and  Finkelstein,  after  coauthoring  a  book 
which  described  Information  engineering,  have  gone  their  separate 
ways. 

Martin  has  written  yet  another  book,  which  Is  titled  Strategic 
Data  Planning  Methodologies. 

Finkelstein  has  freed  himself  from  a  busy  schedule  of  promoting 
information  engineering  in  order  to  develop  software  to  bridge 
the  gap  between  data  design  and  systems  Implementation. 

Since  they  have  separated,  Martin  has  become  somewhat  testy  about 
being  identified  closely  with  Finkelstein. 
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When  asked  during  a  recent  interview  whether  he  was  talking 
about  information  engineering  as  he  and  Finkeistein  described  in 
their  book,  Martin  replied:  "I  think  information  engineering  is  a 
buzzword  like  IRM,  which  is  useless  unless  you  link  it  to  the 
tools  and  the  software  that  are  now  becoming  available.  You 
know  how  these  buzzwords  go  through  the  industry.  Lots  of 
people,  for  example,  when  they  use  the  term  'software  engi- 
neering' don't  mean  anything  that  has  any  flavor  of  engineering 
about  it  at  all." 

Then  when  asked  about  the  tools,  he  mentioned  Data  Designer 
from  Data  Designer,  Inc.,  and  HOS  software  from  Higher  Order 
Software.  No  mention  was  made  of  Information  Engineering 
Ltd.  (Australia  and  New  Zealand)  or  Information  Methods  (U.S.) 
which  are  the  "Information  Engineering  Group  of  Companies" 
established  by  Finkeistein. 

With  IBM,  James  Martin,  and  Clive  Finkeistein  (among  others)  out  promoting  a 
"big  bang"  approach  to  information  systems,  something  is  bound  to  happen. 
And  that  something  will  probably  shift  the  emphasis  of  current  methodologies 
and  tools  regardless  of  whether  or  not  it  is  successful. 

Some  of  the  implications  of  what  is  being  proposed  are  somewhat 
frightening.  Consider  the  master  spellbinder  Martin  as  he  promotes  "data 
planning,"  "information  engineering,"  or  BSP: 

"It  is  expensive  to  develop  the  data  bases  a  corporation  needs." 

"...The  costs  should  not  all  be  borne  by  the  first  applications  or  the 
first  user  department." 

"Maximizing  return  on  DP  investment  in  the  short  term  requires  differ- 
ent actions  from  maximizing  it  over  a  three-  or  four-year  period." 
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"...Anybody  who  presents  a  multiyear  project  is  not  going  to  be  well 
received." 

Therefore,  "Data  base  expenditure  is  a  type  of  cost  that  ought  to  be 
capitalized." 

"To  charge  its  cost  to  this  year's  users  does  not  make  sense,  especially 
as  it  takes  some  years  to  develop  the  applications  to  utilize  data  bases 
fully." 


•  If  past  experience  is  any  guide,  the  IBM  salesman  or  James  Martin  will  not  be 
around  when  the  corporate  controller  tries  to  find  the  assets.  They  will  be  off 
promoting  "information  physics"  or  some  other  new  concept  which  will  really 
be  the  latest  buzzword  to  solve  the  same  problem,  i.e.,  what  are  the  require- 
ments? ^  ' 

•  The  problems  with  building  the  ultimate  data  base  are  going  to  take  us  right 
back  to  the  productivity  problem.  ■ 

Good  analysts/programmers  do  not  want  to  be  concerned  with  systems 
and  program  documentation,  much  less  the  nitty-gritty  of  detailed  data 
base  design,  development,  and  documentation.  Such  work  really  re- 
quires high  clerical  aptitude  and  a  love  for  infinite  detail. 

During  the  three  to  four  years  this  data  base  is  being  built,  the  only 
programming  work  will  be  associated  with  maintenance  of  existing 
systems.  Both  the  drudgery  of  building  the  data  base  and  the  rather 
routine  work  of  maintaining  existing  systems  will  tend  to  force  the 
good  people  out. 

The  people  who  have  been  hired  to  build  the  data  base  will  gravitate 
toward  systems  development  where  they  will  usually  fall  at  the  low  end 
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of  the  productivity  scale.  This  will  result  in  a  massive  data  base  with 
poor  systems  to  access  it,  the  opposite  of  the  DBMS  experience  where 
expensive  general  purpose  systems  were  installed  without  adequate 
data. 

•  As  the  companies  who  adopt  BSP  (Information  engineering)  expend  their 
systems  resources  building  the  corporate  data  base,  distributed  information 
bases  located  in  the  office  (on  personal  computers,  electronic  filing  systems, 
data  base  machines,  System/38s,  etc.)  will  have  been  developed  by  end  users 
to  run  the  day-to-day  business. 

•  This  scenario  is  based  on  INPUT'S  opinion  that  IBM's  grand  strategy  is  designed 
to  exploit  both  sides  of  the  large  central  versus  small  distributed  system 
controversy. 

2.        IBM  PROVIDED  PRODUCTIVITY  PRODUCTS 

•  Respondents  were  asked  whether  they  used  IBM  productivity  products  and 
what  were  their  ratings  or  comments  concerning  them.  The  wide  range  of 
responses  to  these  questions  will  be  summarized  by  product  with  appropriate 
comments  from  individual  respondents.  The  general  reactions  are  summarized 
in  Exhibit  IV- 18. 

IIS  was  known  by  most  respondents  and  their  reactions  were  generally 
favorable. 

SCE  was  a  big  IIS  user  and  was  enthusiastic. 

Singer  had  the  only  negative  reaction,  stating  that  they  had  used 
it,  and  it  was  only  fair. 

MH  intends  to  install  and  use  it  in  developing  training  products. 
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NS  had  it  installed  but  no  longer  uses  it. 

MSA  stated  it  was  "pretty  good,"  was  relatively  inexpensive,  and 
had  "unexpected  uses." 

STAIRS  was  not  met  with  very  much  enthusiasm. 

SCE  said  it  was  "old"  and  "fair."  ~ 

SAS  merely  said  it  was  not  a  product. 

APL  was  generally  known  and  favorably  received  for  certain  applica- 
tions. 

SCE  said  it  tested  at  24:1  over  COBOL  in  number  of  statements 
per  program. 

MSA  reacted  negatively,  stating  one  should  distinguish  between 
the  language  and  the  implementation.  Specifically,  they  thought 
it  was  extremely  expensive  ("wretched  performance"). 

Plancode  was  not  well  known,  and  SAS  considered  it  an  application 
package. 

CIS  was  generally  known  and  not  at  all  well  regarded.  Comments  were: 
"Terrible."  (SCE) 
"Bad."  (C  &  S) 
"Disaster."  (SAS) 
"Primitive."  (MSA) 
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ADF  was  generally  well  received  by  the  people  who  knew  about  it,  but 
it  was  used  by  only  three  respondents. 

SAS,  which  has  to  interface  with  IMS,  had  the  following 
comments:  "It's  an  example  of  a  methodology  embedded  in  a 
program.  I  guess  it  is  OK  if  you  want  to  change  your  solution  to 
fit  the  system.  IMS  is  the  problem." 

DMS  was  well  known  and  was  greeted  in  a  negative  fashion  by  everyone 
except  two  individuals  who  were  directly  involved  in  its  development 
(at  CIC  and  Sundance). 

"Very  bad,  under  CICS  it  is  a  resource  burner  and  can  bring  down 
the  network."  (C  &  S) 

"We  had  it  installed  and  dropped  it;  the  8100  was  a  poor  per- 
former." (NS) 

"Too  simpleminded  -  OK  for  an  idiot  who  can't  design  a 
screen."  (SAS) 

"Crude."  (MSA) 

DMS  was  developed  as  a  joint  effort  by  IBM  and  Royal  Globe 
Insurance  in  order  to  distribute  processing  capabilities  to  branch 
offices.  The  3790  was  difficult  to  use,  and  they  developed  DMS 
to  get  applications  up.  Irv  Kelson  (Sundance)  was  with  IBM  at 
that  time,  and  Bob  Dadd  (CIC)  was  at  Royal  Globe. 

SQL/DS  was  not  well  known  among  the  user  respondents  because  they 
are  oriented  toward  large  systems,  and  it  is  not  considered  an  option 
with  them.  Among  the  vendors  the  reaction  was  mixed. 
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"I  don't  know  much  about  it,  but  it  is  big  and  slow,"  (SAS) 


Even  the  reaction  fronn  MSA,  which  was  rated  positive,  stated: 
"Good  design,  conservative  implementation." 

SPF  (ISPF)  was  the  most  highly  rated  product.  Everyone  who  had  SPF 
installed  seemed  pleased  with  it.  Typical  reactions  were:  ~ 

"Good."  (C  &  S) 

"Very  pleased."  (UNO) 

"The  first  decent  product  IBM  has  built."  (SAS) 

"Easy  to  use  and  has  a  good  editor,  but  it  is  a  resource  burner." 
(MSA,  whose  answer  was  rated  as  positive). 

Despite  the  general  enthusiasm,  however.  Southern  Railway 
(NS),  which  was  one  of  the  first  companies  to  go  completely  on- 
line for  systems  development,  had  this  to  say:  "We  tried  it,  but 
we  can't  afford  it.  With  60  users  it  brought  the  3033  to  its 
knees." 

System  IPO  was  well  received  by  those  who  felt  they  could  rate  its 
quality.  The  software  vendors  who  must  deal  with  IBM  systems  soft- 
ware on  a  broad  basis  had  the  following  to  say: 

"It  is  great  if  you  don't  know  what  you  are  doing."  (SAS,  whose 
response  was  rated  positive  on  the  basis  that  ordinary  users  do 
have  difficulty  dealing  with  complex  systems.) 
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"Greatest  thing  since  grits."  (MSA's  Southern  expression  of 
satisfaction  which  is  not  easily  translatable  but  is  definitely 
positive.) 

SMP  also  received  a  generally  favorable  rating  among  both  users  and 
software  vendors.  The  only  negative  reaction  was  from  McGraw-Hill 
who  had  recently  thrown  the  package  out.  In  addition,  one  user  who 
rated  the  package  itself  as  "excellent"  stated  that  the  fact  it  was 
required  was  "poor." 

Only  one  respondent  (SAS)  saw  fit  to  comment  on  an  IBM  productivity 
product  not  on  the  list.  Qube  (query  by  example)  was  reported  to  be  "a 
big,  slow,  expensive  solution." 

•         Some  respondents  did  make  general  comments  about  the  list  of  productivity 
products  and  IBM's  efforts  in  this  area. 

"The  productivity  aids  are  a  necessity  in  order  to  use  IBM  systems." 
(UNO 

"On  a  scale  of  0-10,  IBM  rates  a  2.  They  have  not  done  anything  for 
any  corporation  which  truly  improves  productivity.  They  only  fix  their 
own  problems  -  hardware,  software,  and  marketing."  (C  &  S) 

"A  good,  full-screen  editor  would  help."  (NS) 

"Most  of  the  so-called  productivity  products  are  really  successor 
products  which  attempt  to  solve  huge  problems  IBM  has  created." 
(SAS) 

"Now  with  SPF  we  see  a  successor  product  (ISPF)  which  deletes  split 
screen  ability.  It  actually  regresses  in  terms  of  product  quality."  (SAS 
implies  that  IBM  found  it  difficult  to  leave  a  good  product  alone.) 
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Sundance  also  stated  that  IBM  would  normally  take  a  good  idea  or 
package  and  ruin  it  by  running  it  through  the  development  process. 
(The  respondent,  Kelson,  felt  this  had  been  done  with  DMS,  which  was 
developed  as  a  simple  tool  and  then  destroyed  as  a  product.) 

NON-IBM  PROVIDED  METHODOLOGIES  AND  TOOLS 

The  productivity  pyramid  gives  graphic  emphasis  to  the  proper  place  of 
methodologies  and  tools  in  a  well-structured  productivity  improvement 
program.  Unless  a  strategy  is  in  place,  it  is  impossible  to  determine  what  the 
proper  tools  are. 

Depending  upon  the  individual  organization's  definition  of  quality,  a 
particular  verification  or  validation  procedure  may  or  may  not  produce 
an  acceptable  system. 

Depending  upon  how  users  are  to  be  involved  in  the  development 
process,  the  choice  of  languages  (DBMS,  requirements  language,  fourth 
generation  language,  etc.)  may  vary  considerably. 

Depending  upon  the  experience  and  orientation  of  management  and  the 
quality  of  data  processing  personnel,  certain  methodologies  and  tools 
employed  during  the  system's  life  cycle  will  be  more  appropriate  than 
others. 

Selective  methodologies  and  tools  out  of  sequence  with  the  produc- 
tivity pyramid  can  have  the  effect  of  trying  to  change  requirements  to 
fit  ordained  solutions.  This  is  seldom  successful  and  has  in  the  past 
contributed  substantially  to  the  productivity  problem  itself. 

INPUT'S  past  research  established  that  67%  of  the  system's  life  cycle  costs 
are  concentrated  in  maintenance  and  enhancements  but  that  the  emphasis  of 
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tools  has  been  on  the  coding  phase,  as  shown  in  Exhibit  iV-19.  This  led  to 
analyses  of  the  applicability  and  impact  of  a  group  of  selected  tools. 

Exhibit  IV-20  presents  the  applicability  of  selected  tools,  and  Exhibit  IV-21 
assesses  the  impact  of  these  tools.  The  charts  are  provided  for  reference 
purposes  to  assist  in  evaluating  the  respondents'  comments  concerning  tools 
and  aids. 

The  distribution  between  "applicability"  and  "impact"  is  based  on  the 
fact  that  specific  tools  may  be  used  (applied)  during  a  certain  phase  of 
the  life  cycle  and  yet  have  significant  impact  on  another  phase  later 
during  a  project. 

For  example,  tools  which  are  applied  during  requirements  and 
specifications  may  have  a  pronounced  effect  on  how  easy  a  system  is  to 
maintain. 

It  becomes  apparent  from  the  charts  that  there  is  no  magic  set  of  "right 
tools."  They  must  be  analyzed  carefully  for  their  applicability  in  each 
specific  environment.  There  are  so  many  "solutions"  being  proposed  to 
improve  productivity  that  all  respondents  expressed  the  need  for  continuing 
evaluation,  and  some  expressed  the  opinion  that  tool  evaluation  itself  was 
becoming  part  of  the  productivity  problem.  The  level  of  evaluation  varies 
tremendously  from  organization  to  organization,  and  frequently  evaluation 
and  even  selection  are  done  in  individual  development  groups  with  little  or  no 
control. 

Exhibit  IV-22  presents  INPUT'S  interpretation  of  what  the  current  status  of 
tool  evaluation  and  selection  is  within  the  organizations  interviewed. 

Four  of  the  respondents  have  a  more  or  less  formal,  centralized  func- 
tion which  is  responsible  for  evaluating  tools  (SCE,  CIC,  MH,  and 
C&S). 
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EXHIBIT  IV-20 
APPLICABILITY  OF  SELECTED  TOOLS 


LIFE-CYCLE 
PHASE 


TOOL 


REQUIRE- 
MENTS 


SPECIFI- 
CATIONS 


DETAIL 
DESIGN 


CODE 


TEST 


MAIN- 
TENANCE 


On-Line  Systems 
•  CMS,  TSO 


DBMS  and  Query 
Languages 

•  IMS,  204,  etc. 


Systems  Design 
Methodologies 

•  Pride,  SDM/70 


Requi  rements 
Languages 

•  PSL/PSA 


Organizational 
Technique 

•  Chief  Programmer 
Team 


Programmer' s 
Workbench 

•  Maestro,  PWB/ 
UNIX 


Structured  Analysis 

•  Jackson 

•  SADT 

•  Structured  Tableau 

•  Warnier-Orr 


Menu-Driven  Program 
•  DMS,  TAPS 


Verification  and 
Validation 

•  Static  and  Dynamic 

•  Structured  Walk- 
Through 


Miscellaneous 

•  PDL  .. 

•  Reusable  Code 
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EXHIBIT  IV-21 
IMPACT  OF  SELECTED  TOOLS 
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Note:     P  =  Primary;  S  =  Secondary 
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EXHIBIT  IV-22 


CURRENT  STATUS  OF  METHODOLOGY 
TOOL  EVALUATION  AND  SELECTION 


RESPONDENT 

CENTRALIZED 
AND 
FORMAL 

EVALUATION"^ 
EFFORT 

MAJOR 
IN-HOUSE 
DEVELOPMENT 

MAJOR 
EVALUATION/ 
SELECTION 

EDP  Departments 

- 

SCE 

Yes 

H 

Yes 

Yourdan  (S) 

Singer 

No 

M 

No 

None 

CIC 

Yes /No 

M 

No 

Yourdan  (E) 

MH 

Yes 

H 

Yes 

OPUS  (S) 

UNC 

No 

L 

No 

No 

C  &  S 

Yes 

M 

NA 

NA 

NS 

No 

M 

Yes 

None 

Vendors 

MPG 

No 

L 

Yes 

None 

SAS 

No 

M 

Yes 

None 

Sundance 

No 

L 

Yes 

None 

MSA 

No 

M 

Yes 

Yourdan  (S)* 
DD/D  (E) 

*  One  Group  Only 

H  =  High,  M  =  Medium,  L  =  Low 
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Two  organizations  (SCE  and  MH)  are  putting  a  substantial  amount  of 
effort  into  evaluating  tools. 

SCE  states  that  50  to  100  tools  are  evaluated  per  year. 

MH,  having  just  established  a  central  responsibility,  stated  the 
task  could  lower  the  productivity  of  the  Decision  Support 
Systems  department. 

Three  organizations  (UNC,  MPG,  and  Sundance)  have  a  very  low  level 
of  effort  in  evaluating  tools. 

UNC  has  a  director  who  reviews  developments  and  documenta- 
tion of  interest. 

MPG  is  firmly  committed  to  fourth  generation  languages  and 
systems  development  concepts. 

Sundance  is  concerned  primarily  with  the  low  end  of  the  line  and 
usually  works  on  problems  which  have  been  fairly  well  defined 
by  the  client. 

The  remainder  of  the  respondents  all  expend  time  based  on  specific 
circumstances  such  as  starting  new  projects,  vendor  sales  pressure, 
user  recommendations,  and  tools  recommended  for  review  by  profes- 
sional associates. 

Three  of  the  EDP  department  respondents  (SCE,  MH,  and  NS)  and  all 
four  of  the  software  vendors  have  developed  or  adapted  methodologies 
and/or  tools  for  their  specific  use.  (Where  these  efforts  are  signifi- 
cant, they  will  be  reviewed  in  the  case  studies.) 
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Yourdon  has  selected  two  respondents  (SCE  and  one  application  group 
in  MSA)  as  their  primary  methodology,  and  its  being  actively  evaluated 
by  CiC. 

MH  has  selected  and  is  implementing  OPUS,  a  methodology  from  IBM- 
Germany.  (This  decision  will  be  discussed  in  the  MH  case  study.  A 
document  on  OPUS  is  available.) 

The  reasons  various  methodologies  and  tools  have  been  rejected 43y  the  respon- 
dents are  best  illustrated  by  their  comments. 

"Using  advanced  methodologies  forces  one  to  change  the  way  systems 
are  built.  Therefore,  tools  and  aids  frequently  fit  (with  the  way 
companies  develop  systems).  Yourdon  methodology  and  system 
development  architecture  developed  themselves."  (SCE) 

"I  am  opposed  to  methodologies;  they  become  an  end  in  themselves. 
Tools  and  aids  are  frequently  of  no  interest  to  the  systems 
developers."  (Singer) 

"Systems  and  technical  standards  frequently  won't  permit  things  some 
people  want  to  bring  in."  (CIC) 

"A  lot  have  been  investigated  but  in  the  past  only  superficially.  DSS 
has  only  gotten  started."  (MH  explaining  the  centralized  review  func- 
tion which  has  only  recently  been  established.) 

"(The  director)  read  about  various  approaches,  but  he  has  not  been 
impressed.  Conventional  systems  approaches  are  still  being 
employed."  (UNC)     ^  . 

"Methodologies  and  structures  are  not  the  answer.  (We)  look  at  promis- 
ing things,  but  most  of  the  solutions  seem  to  be  more  trouble  than  they 
are  worth."  (NS) 
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"Fourth  Generation  Systems  used  intelligently  address  most  of  the 
methodology  and  tools  being  touted."  (MPG) 

"We  do  not  believe  in  canned  methodology  or  approaches."  (Sundance) 

"Most  of  the  structured  programming  thing  has  been  overblown.  The 
main  people  who  have  benefitted  have  been  consultants  who  now  have  a 
whole  new  area  to  be  experts  in."  (SAS) 

"It  is  not  considered  necessary  to  investigate  all  (methodologies  and 
aids)  on  a  formal  basis  -  individual  project  leaders  select  what  they 
need,  and  they  may  recommend  to  others."  (MSA) 

•  Respondents  were  asked  about  their  knowledge  or  use  of  five  specific 
methodologies  and/or  tools  -  pseudo  code,  Jackson  methodology,  SADT,  HlPO, 
and  Nassi-Schneiderman  charts.  Their  answers  are  recorded  in  Exhibit  iV-23. 
When  asked  which  they  considered  to  be  the  most  promising,  the  following 
answers  were  received: 

"Yourdon  is  generally  good;  the  others  tend  to  focus  on  part  of  the 
problem."  (SCE) 

"PSL/PSA  is  promising;  we  support  iSDOS  at  University  of  Michigan." 
(SCE) 

"Pseudo  code  and  FOCUS  are  interesting."  (Singer) 

"A  standard  approach,  whether  HIPO  or  something  else,  is  a  good 
idea."  (CiC) 

MH  stated  they  liked  OPUS  against  other  things  evaluated. 
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EXHIBIT  lV-23 

RESPONDENTS'  REACTIONS  TO  SPECIFIC  METHODOLOGIES  (TOOLS) 


RESPONDENT 

PSEUDO 
CODE 

JACKSON 
METHODOLOGY 

SADT 

HIPO 

NASSI- 
SCHNEIDER- 
MAN 

EDP 

1 

- 

Departments 

SCE 

All  Specs 
Used 

Have  Used 

Have 
Looked  At 

Terrible 

1 ncorporated 

in  Their 
Methodology 

Singer 

Interested 

Know  About 

Not  Known 

Know  About 

Not  Known 

CIC 

Know  About 

Know  About 

Not  Known 

/"*  1    r*\           •  _i_ 

Good  Despite 
Controversy 

Left 
Him  Cold 

MH 

OPUS 
Incorporates 

Know  About 

Know  About 

Have  Used 

Know  About 

UNC 

Know  About 

Not  Known 

Not  Known 

Know  About 

Not  Known 

CSS 

Know  About 

Know  About 

Not  Known 

Know  About 

Not  Known 

NS 

Know  About 

Not  Known 

Not  Known 

Have  Used 

Know  About 

So  "Ft  w  t*p 

<mJ\J  I   L  VV  C3  I  C 

Vendors 

MFC 

Have  Used 

Know  About 

Not  Known 

Have  Used 

Not  Known 

Sundance 

Have  Used 

Not  Known 

Not  Known 

Have  Used 

Not  Known 

SAS 

Know  About 

Know  About 

Know  About 

Know  About 

Know  About 

MSA 

Have  Used 

Decided 
Against 

Decided 
Against 

Have  Used 

Limited 
Use 
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"Languages  and  purchased  packages  will  get  EDP  out  of  the  develop- 
nnent  business."  (C  &  S) 

"Good  prototyping  capability  could  help,  especially  for  users."  (NS) 

"Pseudo  code  is  very  good,  especially  for  communications."  (Sundance) 

"They  are  not  for  us.  Methodologies  are  good  for  those  who  don't 
understand.  Playing  is  learning  the  rules;  experience  is  learning  the 
exceptions."  (SAS) 

"Yourdon  has  been  successful  in  Payroll  Development,  which  is  one  of 
our  biggest  groups.  It  may  catch  on  in  other  areas."  (MSA) 

•  There  are  so  many  methodologies  and  tools  that  they  are  difficult  to  eval- 
uate, and  no  individual  is  usually  familiar  with  all  of  the  alternatives.  The 
general  reactions  seemed  to  fall  into  two  categories. 

The  EDP  department  respondents  were  frequently  removed  from  first- 
hand knowledge  of  methodologies  and  tools.  Therefore,  they  had  only 
general  acquaintance  and  opinions.  They  felt  insecure  in  that  they  kept 
looking  for  solutions  but  did  not  feel  methodologies  or  tools  existed 
which  could  really  improve  good  project  management. 

The  software  vendor  respondents  feel  their  work  is  "different"  and  that 
systems  programming  requires  each  project  leader  to  have  control  over 
his  own  destiny.  Commercially  available  methodologies  and  tools 
might  be  all  right  for  regular  data  processing  projects,  but  their  work 
requires  creativity  and  freedom. 
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METHODOLOGIES  AND  TOOLS  REQUIRED 


The  respondents'  answers  to  what  they  felt  would  be  of  most  benefit  to  them 
in  improving  productivity  have  been  given  earlier  in  this  section.  It  is  signifi- 
cant that  those  answers  were  not  very  specific  in  terms  of  methodology  or 
tools. 

User  statements  of  requirements  are  probably  tentative  because  users 
are  not  yet  comfortable  that: 

They  know  and  understand  what  is  already  available. 

They  are  making  effective  use  of  the  methodologies  and  tools 
they  already  have. 

There  was  also  a  tendency  to  concentrate  on  the  micro  and  the 
macro.  Something  specific  like  a  "good,  full-screen  editor"  will  be 
mentioned  by  one  respondent  while  another  requests  "a  good  manage- 
ment training  course."  r 

The  nature  of  the  responses  indicates  there  are  already  too  many 
"solutions"  to  a  problem  which  is  still  undefined. 

The  problem  of  definition  reflects  the  general  concern  about  what 
■  productivity  really  means  and  the  lack  of  adequate  measures  to  eval- 
uate what  would  be  most  effective  in  improving  productivity. 

The  responses  also  demonstrate  that  individual  respondents  do  not  yet 
have  a  productivity  improvement  plan.  If  they  did,  they  would  be  able 
to  isolate  specific  requirements  to  implement  their  strategies. 

It  is  possible,  however,  to  formulate  a  general  list  from  the  user  responses. 
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There  appears  to  be  a  need  for  a  "fifth  generation  language"  which 
could  be  used  by  systems  developers  who  "must  currently  learn  many 
languages,  tools,  and  methodologies."  This  request  was  voiced  by  both 
SCE  and  MPG.  It  refers  to  actual  implementation  of  a  language  with 
power  to:  .  ' 

Effectively  implement  a  methodology  which  would  span  the 
entire  system  life  cycle. 

Provide  facilities  which  would  ultimately  free  systems  analysts 
of  building  requirements  since  it  would  be  "user  friendly"  enough 
to  permit  users  to  communicate  their  requirements  to  the 
developers. 

The  user  responses  also  pointed  to  the  need  for  improving  communica- 
tions to  facilitate  broadbased  management.  "Good,  short  training 
courses  on  systems  productivity  for  management"  was  the  request  of 
one  respondent.  Interactive  training  and  improved  prompting  capabil- 
ity within  methodologies  might  provide  more  value  than  putting  addi- 
tional tools  in  the  hands  of  programmers. 

There  is  also  an  implied  need  for  improvement  in  performance  and 
quality  of  the  IBM  host  hardware/software  systems.  Many  respondents 
mentioned  a  variety  of  things  which  reflected  this: 

Productivity  aids  were  discarded  because  of  their  performance 
characteristics. 

Relational  data  models  have  not  been  emphasized  on  large 
systems  because  of  the  burdensome  overhead  associated  with 
current  operating  systems. 
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Two  respondents  specifically  requested  stability,  and  improve- 
ment of  operating  systems  is  the  most  beneficial  thing  which 
could  occur  in  improving  productivity. 

While  it  might  appear  that  this  is  beyond  the  normal  definition 
of  a  productivity  improvement  methodology  or  tool,  data  base 
machines  and  other  distributed  computer  architecture  might 
provide  a  real  boost  to  productivity.  ~ 

Last  but  not  least,  a  good  data  base  containing  detailed  information 
and  productivity  improvement  characteristics  of  current  methodologies 
and  tools  (along  with  training  in  their  use)  would  be  of  substantial 
benefit  to  end  users  in  their  evaluation  and  installation  efforts.  This  is 
true  for  several  reasons  identified  by  respondents: 

Most  consultants  are  pushing  a  particular  methodology  or  tool. 

Vendors  obviously  suffer  from  bias  in  presenting  their  products. 

Users  need  help  with  the  problem  of  evaluation. 

•  It  is  INPUT'S  opinion  that  help  is  needed  where  dollars  are  being  spent  -  on 
maintenance  and  enhancement.  Exhibit  IV-23  shows  which  of  the  representa- 
tive tools  affect  this  phase  of  the  life  cycle.  The  difficulty  arises  in  the 
general  perception  and  understanding  of  the  productivity  problem. 

Many  people  do  not  understand  that  early  effort  in  systems  develop- 
ment can  save  substantially  on  maintenance  and  enhancement. 

More  important,  some  people  do  not  care  about  later  expense  but  only 
about  meeting  current  budgets  and/or  schedules. 
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This  brings  us  rigiit  back  to  the  productivity  pyramid  and  the  necessity 
of  having  an  improvement  strategy  with  a  solid  foundation  before 
determining  what  the  right  tools  are.  At  present  very  few  companies 
have  such  a  strategy. 

The  right  tools  depend  upon  the  company's  objectives,  project  size,  cost 
effectiveness,  and  a  variety  of  factors.  Custom  tailored  methodologies  and 
tools  will  probably  be  the  rule  in  many  data  processing  departments  and 
software  vendor  organizations  for  some  time. 

However,  INPUT  does  see  a  major  requirement  for  integrated  data  definition 
and  systems  development  software  to  facilitate  developing,  analyzing,  and 
changing  information  bases.  For  lack  of  a  better  example,  let's  take  "infor- 
mation engineering"  as  proposed  by  Finkelstein  and  Martin.  Our  preference 
would  be  as  follows: 

We  do  not  think  a  major  data  definition/information  resource  effort 
should  be  undertaken  (either  under  prompting  from  IBM  on  BSP  or 
Martin  in  Strategic  Data  Planning  Methodologies)  with  dependency 
upon  independently  developed  implementation  software. 

The  requirement  we  see  is  for  a  system  similar  in  concept  to  that 
proposed  by  Finkelstein.  (Although  additional  analysis  would  be  re- 
quired before  we  could  be  sure  his  implementation  would  satisfy  the 
requirements  as  we  envision  them.) 
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ASSESSMENT  OF  IBM  STRATEGIES 


A.       REACTION  TO  ASDC 

•  There  was  no  reaction  to  ASDC  among  the  EDP  department  respondents;  they 
had  never  heard  of  it  in  most  cases.  Some  said  they  thought  they  had  read 
something  about  it  but  no  one  could  really  comment. 

•  The  vendor  responses  were  a  little  better,  but  not  very  informative: 

Sundance  stated  that  while  they  were  not  familiar  with  ASDC  as  such, 
they  did  know  about  meetings  held  to  encourage  software  houses  to 
develop  System/38  support. 

SAS  stated  they  had  heard  about  it  but  really  didn't  know  much  about 
the  details. 

•  Respondents  were  also  asked  a  more  general  question  concerning  IBM's  en- 
couragement of  independent  software  houses  to  develop  applications  pack- 
ages. This  question  elicited  more  responses: 

"Superb,  and  it  will  continue.  IBM  can't  do  the  job  without  the  soft- 
ware industry."  (SCE) 


-  149- 


INPUT 


"Doubt  it  (IBM's  encouragement).  Maybe  it  is  expedient,  but  they  (IBM) 
really  want  the  whole  pie."  (Singer) 

"IBM  has  a  problem  getting  hardware  systems  installed.  They  will 
encourage  anyone  to  get  the  job  done."  (MH) 

"IBM  has  only  limited  resources,  and  they  will  encourage  development 
of  lUPs  because  that  will  make  hardware  more  marketable."  (UNC)~ 

"This  is  a  plus,  but  IBM  was  forced  to  do  it."  (C  &  S) 

"IBM  has  to  do  this  to  sell  iron.  Also  they  can  obtain  software  products 
for  their  benefit."  (NS) 

"They  have  decided  to  become  the  low-cost,  high-volume,  hardware 
producer.  They  have  found  less  profit  in  software."  (MPG) 

"This  is  good  and  has  been  forced  by  DDR  and  small  standalone 
systems.  It  encourages  all  types  of  flexibility  and  innovative 
solutions.  However,  it  makes  for  problems  of  selection  and  compli- 
cates generalization  (when  IBM  wants  to  acquire)."  (Sundance) 

"Good  idea.  IBM  still  wants  to  be  the  sole  source  of  all  problem  solu- 
tions but  they  are  having  problems  doing  that.  IBM  can't  expect  to  be 
expert  in  all  areas."  (SAS) 

"At  certain  levels  it  helps  them  (IBM)  install  hardware.  IBM  has  been 
helpful  although  we  are  competitors."  (MSA) 

•         The  general  consensus  seems  to  be  that: 

IBM  is  not  encouraging  independent  applications  software  development 
because  they  are  altruistic;  they  are  doing  it  because  they  have  been 
forced  to. 
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IBM's  primary  orientation  has  been  (and  continues  to  be)  hardware.  If 
IBM  (or  its  customers)  cannot  develop  applications  software  fast 
enough  to  permit  installation,  they  will  encourage  outside  development. 

They  probably  would  like  all  of  the  revenue,  but  it  is  unlikely,  based  on 
past  performance,  that  they  can  satisfy  the  enormous  demand  hardware 
sales  have  generated. 

B.       PRECONFIGURED  SYSTEMS 

•         Everyone,  including  EDP  departments,  had  some  feelings  about  preconfigured 
systems  such  as  those  announced  for  the  4321  and  4331-1  I  (SSX/VSE). 

"They  (IBM)  have  to  bundle  and  even  design  hardware  and  software 
together  like  the  System/38,  which  is  a  real  sleeper.  This  strategy  has 
one  big  advantage  -  the  customer  finds  the  system  usable."  (SCE) 

"I  doubt  whether  they  will  do  it  on  the  high  end;  IBM  wants  the  revenue 
from  the  complex  systems  (software)  that  have  evolved."  (Singer) 

"Will  see  more  prepackaging  on  small  systems,  and  it  may  bubble  up. 
However,  if  it  does  expand,  functions  will  be  limited  and  customizing 
will  be  necessary."  (UNO 

C  &  S  did  not  think  anyone  with  a  large  system  would  want  a  prepack- 
aged system  "as  is"  but  thought  it  could  help  IBM. 

"Conceptually  this  must  continue  whether  through  prepackaging  in 
software,  firmware,  or  hardware.  The  3081  already  has  stuff  going 
under  the  covers  (I/O  functions)."  (NS) 
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"It  means  no  systenns  programmers  will  be  required  on  the  fow  end. 
They  (IBM)  have  to  compete  with  DEC  and  be  easy  to  install."  (MPG) 

"Packaging  is  a  trend.  System/38  had  the  advantage  of  starting  with 
integrated  design,  but  even  for  the  regular  line  of  systems  the  direction 
is  clear."  (Sundance) 

"Great  for  first  time  users,  but  limitations  are  there  and  should  be 
understood.  IBM  should  not  minimize  the  limitations,  but  they  probably 
will."  (SAS) 

MSA  served  as  an  IBM  test  site  for  the  4321  and  4331-1  I  (SSX/VSE)  and 
had  this  to  say: 

"Reaction  is  generally  positive  -  it  is  a  good  thing  for  the  inex- 
perienced user." 

"Some  shortcomings,  but  Release  I  is  very  good." 

The  application  of  the  concept  "  corresponds  to  the  IBM  organi- 
zational cutoff." 

"There  may  be  problems  upgrading  (SSX/VSE)  to  the  4341  unless 
IBM  provides  a  bridge.  There  are  architectural  differences,  and 
it  may  require  hardware  changes  to  upgrade." 

•  The  general  reaction  seems  to  be  that  more  prepackaged  systems  (or  a  more 
complex  hardware/firmware/software  strategy)  is  a  trend  but  that  at  present 
it  is  probably  limited  to  systems  coming  from  the  IBM  Information  Systems 
and  Communications  Group  (systems  below  4341). 
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C.       IBM  INFORMATION  NETWORK 


•  While  the  question  concerning  the  IBM  Information  Network  was  asked  of  the 
EDP  department  respondents,  most  did  not  have  opinions  about  it.  This  is 
probably  because  these  large  systems  users  install  all  the  hardware  end  pro- 
ductivity products  they  need,  and  the  early  announcement  of  the  Information 
Network  was  not  seen  as  applying  to  them.  The  comments  which  were^re- 
ceived  are  as  follows: 

SCE  stated: 

"it  is  primarily  a  question  of  competitive  positioning  for  the 
future." 

"It  helps  smaller  users  with  pre-installation  assistance.  Major 
customers  are  not  affected." 

"The  network  will  expand  -  look  for  IIS  type  stuff  which  will 
have  dual  benefits  for  IBM." 

Singer  did  not  see  much  use  for  it.  They  felt  that  third-party  sources 
would  probabJy  be  cheaper  for  backup  and  overflow,  and  if  the  produc- 
tivity packages  were  attractive  they  would  install  them. 

McGraw-Hill  viewed  IBM  as  a  possible  competitor  for  the  types  of 
information  product  offerings  they  currently  have  (e.g.,  DRI)  and  even 
for  the  offerings  of  the  internal  Information  Center.  (This  is  an  inter- 
esting thought:  will  IBM  really  try  to  sell  directly  to  end  users  when 
the  internal  EDP  department  is  "true  blue"?) 

C  &  S  tried  using  the  network  in  Tampa  and  found  it  "much  too  costly." 
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•  The  software  vendors  ail  had  opinions  concerning  the  IBM  Information  Net- 
work, although  it  is  not  clear  that  they  were  thought  through  any  better  than 
the  IBM  customer  reactions. 

MPG  felt  the  current  offerings  were  "supplementary  and  complemen- 
tary" to  customers'  internal  systems  resources,  but  also  speculated  that 
IBM  would  come  out  with  a  proprietary  fourth  generation  system  for 
users  of  the  network. 

Sundance  thought  it  was  a  good  idea  because  the  new  user  would  have 
an  opportunity  to  "play"  with  a  system  before  making  a  commitment  to 
a  new  tool  or  package. 

SAS  felt  it  looked  "just  ike  any  service  bureau  -  that's  all." 

MSA  stated  it  might  help  them  (and  others)  get  a  quick  look  at  new 
systems,  but  they  would  still  have  to  install  for  themselves  because  the 
current  offering  is  "not  designed  (packaged)  for  production  use." 

•  The  most  thoughtful  predictions  for  future  network  directions  were  as  follows: 

"It  is  heading  in  an  interesting  direction.  It  has  good  libraries  of  prod- 
ucts, and  these  will  expand.  There  is  an  explosion  of  information,  and 
IBM  will  be  forced  to  include  competitive  information  on  systems 
products  and  services."  (Singer) 

"In  the  future,  advanced  network  management  services  are  a  definite 
possibility."  (C  &  S) 

"There  is  not  only  the  potential  but  the  probability  that  IBM  will 
compete  against  the  publishing  industry  for  electronic  information 
services."  (MH) 
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"Interconnection  of  various  users  and  clients,  its  future  is  as  o  com- 
munications network."  (SAS) 

•  Since  the  interviews  were  conducted,  IBM  has  been  awarded  the  contract  to 
run  the  network  which  was  designed  for  sponsors  of  the  insurance  institute  for 
Research.  It  is  felt  that  this  has  revealed  the  potential  of  the  Information 
Network.  Consider  the  following: 

Some  of  the  sponsoring  insurance  companies  have  competitive  main- 
frames installed,  and  IBM  now  has  them  tied  into  their  network.  What 
an  opportunity! 

On  the  other  side  of  the  coin,  thousands  of  agents  will  be  tied  mto  the 
network.  They  will  need  terminal  equipment  and  information  such  as 
rates,  regulations,  and  potential  legislation  of  importance  -  a  ready- 
made  market  for  existing  hardware  products  and  new  information 
services. 

Information  on  IBM  products  is  already  on-line  to  support  anyone  who  is 
interested,  and  as  suggested  by  one  respondent,  training  courses  can 
also  be  supplied. 

Look  for  IBM  to  push  data  security  and  backup  among  users  of  the 
network. 

Last  but  not  least,  look  for  them  to  have  policy  management  and  other 
insurance  packages  the  network  customers  can  try  out  and  perhaps 
continue  to  use  due  to  the  economics  and/or  timing  of  internal  installa- 
tion. (This  could  be  sold  on  the  basis  of  productivity  improvement. 
Why  use  your  precious  systems  resource  to  develop  a  custom  system 
when  we  can  provide  the  service  -  especially  if  they  have  the  cus- 
tomers' files  for  backup?) 
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D.  EFFECTS  OF  NETWORK  PRODUCTIVITY  PRODUCTS  (MVSPS  AND  VMPS) 

•  The  respondents  did  not  react  specifically  to  MVSPS  and  VMPS  even  though 
these  were  incorporated  in  the  question.  The  reason  for  this  seems  to  be 
inherent  in  reactions  to  the  Information  Network  described  above: 

Most  respondents  did  not  feel  they  would  be  using  the  network  because 
it  was  directed  primarily  to  inexperienced  users. 

They  also  felt  that  they  would  prefer  to  install  any  productivity  aids 
they  planned  to  use  on  a  continuing  basis. 

For  these  reasons,  a  careful  analysis  (or  serious  consideration)  had  not 
been  given  to  the  productivity  products. 

•  Generally  speaking,  the  respondents  felt  MVSPS  and  VMPS  would  be  good  for 
first  time  and  inexperienced  users  and  would  help  IBM  with  hardware  installa- 
tions. 

E,  IBM  SOFTWARE  STRATEGIES  FOR  LOW-END  MACHINES 

•  IBM  strategies  for  low-end  machines  were  not  of  a  great  deal  of  interest  to 
some  of  the  EDP  department  respondents  since  most  of  them  are  pursuing 
distributed  processing  solutions  within  either  an  SNA  or  competitive  architec- 
ture. However,  some  comments  were  received: 

"System/38  is  the  wave  of  the  future.  They  will  encourage  third-party 
development  for  the  43XX  because  it  doesn't  have  System/38  capabil- 
ity." (SCE) 
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"No  knowledge,  but  I  assume  they  want  to  make  money  from 
software."  (This  comment  by  MH  is  interpreted  to  mean  that  IBM  will 
eventually  seek  to  control  applications  software  sales  despite  their 
current  encouragement  of  third-party  development.) 

"The  (software)  revenue  is  very  important  to  them.  They  will  do  any- 
thing (bundling,  firmware,  etc.)  to  be  sure  they  don't  lose  it."  (Singer) 

•         Vendor  analysis  of  IBM's  software  strategies  for  small-scale  systems  was 
somewhat  tempered  by  their  particular  orientation. 

"IBM  is  interested  in  installing  hardware.  As  pointed  out  previously,  if 
fourth  generation  language  approaches  help  install  systems  five  times 
as  fast,  IBM  will  benefit.  This  will  be  apparent  to  IBM,  and  they  will 
encourage  development  from  any  source."  (MPG) 

"i  think  this  has  been  covered,  but  here  is  the  summary:  I)  make 
systems  easy  to  use,  2)  encourage  any  kind  of  software  development  in 
order  to  sell  iron,  and  3)  get  some  kind  of  system  into  the  customers' 
hands."  (Sundance) 

"(IBM)  will  continue  to  depend  on  independent  vendors.  I  am  not  sure 
they  will  ever  be  able  to  compete  effectively  in  software  market 
(applications)  at  the  low  end  (or  high  end  for  that  matter)."  (MSA) 
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SOFTWARE  DEVELOPMENT  APPROACH  BY  EDP  DEPARTMENTS 
INTRODUCTION  AND  SUMMARY 


•  The  companies  interviewed  were  selected  to  obtain  both  broad  industry  repre- 
sentation and  to  review  contrasting  approaches  to  the  planning,  inripfementa- 
tion,  and  control  of  software  development  activities.  In  addition,  the  partic- 
ular companies  were  chosen  to  demonstrate  various  reactions  to  the  produc- 
tivity problem. 

•  With  such  a  small  research  base,  no  attempt  was  made  to  pursue  the  use  of 
particular  methodology  and  tools  or  even  to  concentrate  on  companies  which 
have  been  "successful"  in  improving  productivity  (although  most  of  the  organi- 
zations are  either  well  respected  in  their  industries  or  have  individuals  associ- 
ated with  them  who  are  well  known). 

•  The  diversity  of  approaches  being  taken  will  become  apparent,  and  we  feel 
this  representative  of  what  is  going  on  in  the  United  States  today  among 
IBM's  customers.  The  one  thing  they  have  in  common  is  the  IBM  hardware  and 
operating  system.  In  addition,  the  impact  of  IBM's  marketing  direction  on 
some  of  the  companies  can  be  seen. 

•  The  individual  case  studies  should  be  used  in  conjunction  with  the  question- 
naires. Where  additional  backup  material  was  obtained,  it  will  be  mentioned 
in  the  particular  study. 
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B.       CASE  STUDY  #1  -  SOUTHERN  CALIFORNIA  EDISON  (SCE) 
I.  BACKGROUND 

•  SCE  has  sincere  concern  about  productivity  in  all  of  its  operations,  and  the 
EDP  department  is  sensitive  to  the  corporate  environment  which  gives 
emphasis  to  solving  the  problem.  SCE  has  taken  the  following  steps  to 
improve  productivity: 

A  Corporate  Productivity  Committee  consisting  of  six  vice  presidents 
meets  quarterly  to  set  direction  and  review  progress. 

Each  manager  has  a  zero-base  budget  from  which  to  develop  his  plan. 

Each  budget  submitted  must  include  a  productivity  plan. 

Managers  are  evaluated  on  meeting  that  plan. 

There  is  a  formal  cash  and  stock  award  program  for  recognizing  signif- 
icant improvements  in  productivity. 

•  Within  this  environment  the  EDP  department  has  developed  an  action-oriented 
plan  which  has  the  following  general  characteristics: 

It  falls  within  the  general  productivity  improvement  strategy  enclosed 
by  IBM,  but  SCE  has  been  highly  selective  in  adopting  IBM  software 
products,  tools,  and  techniques. 

The  emphasis  in  systems  development  has  been  upon  a  functional 
breakdown  during  implementation.  This  obviates  a  "big  bang"  project 
with  first  results  scheduled  on  a  two  to  five  year  timeframe.  This 
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approach  provides  management  and  users  with  alternatives  to  how  the 
system  will  "grow"  during  implementation. 

The  budget  process  and  functional  approach  to  systems  development 
have  forced  a  close  EDP-user  relationship  from  the  planning  stage 
through  the  entire  system  life  cycle  (maintenance  budgets  get  reset  to 
zero  also).  In  addition,  the  emphasis  on  productivity  in  the  company 
has  assured  top  management  awareness  and  involvement. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

Starting  at  the  beginning  of  the  year  (1/82)  SCE  established  a  Computer  User 
Services  (CUS)  department  which  is  responsible  for  the  following: 

Evaluation  of  user-oriented  tools  and  aids  (including  personal  com- 
puters). 

Training  of  users  in  the  use  of  computer  facilities  (both  business  and 
engineering). 

Operations  of  a  user  computer  center  (3033UP). 

Responsibility  for  office  systems. 

CUS  is  the  most  ambitious  implementation  of  an  information  center  that  we 
have  seen.  It  is  especially  comprehensive  in  its  inclusion  of  outside  timeshar- 
ing services,  personal  computers,  and  office  systems. 

CUS  provides  user  development  tools  which  are  also  made  available  to  regular 
applications  developers  for  prototyping.  This  interfacing  between  the  conven- 
tional systems  development  activity  and  user  development  is  extremely 
important;  it  permits  certain  productivity  systems  to  be  developed  and  in- 
stalled using  these  tools. 


The  systems  development  process  takes  place  in  the  management  and  budget- 
ary phases  described  above.  It  is  essentially  top  down  and  can  be  outlined  as 
follows: 

Determine  functions. 

Prioritize  functions.  ~ 
Schedule  them. 

Assign  teams  (user-EDP,  six  to  seven  people). 

Change  priorities  as  required. 

Success  of  the  process  is  measured  by  on-time  completion  of  functions,  and 
because  of  the  extremely  modular  systems  design,  there  are  no  big  surprises. 
Other  general  measures  are: 

They  currently  devote  70%  of  their  resources  to  development  and  only 
30%  to  maintenance.  (If  they  define  development  and  maintenance 
properly,  this  is  certainly  good  compared  to  33%  development  and  67% 
maintenance  in  the  industry.) 

Their  personnel  turnover  rate  is  12%  compared  to  19%  in  their  indus- 
try. 

However,  they  do  not  currently  have  the  tools  to  measure  productivity.  They 
recognize  this  need  and  are  planning  to  start  function  analysis  to  rectify  the 
situation.  (They  supposedly  have  already  collected  substantial  data  during  the 
development  process,  but  it  remains  unanalyzed.) 
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3.        TOOLS  AND  TECHNIQUES  EMPLOYED 


•  SCE  has  adopted  and  tailored  Yourdan  methodology  to  their  particular  needs. 

•  They  have  developed  a  generalized  CICS  architecture  for  the  development  of 
on-line  systems.  (They  are  the  largest  SNA/CICS  user  and  serve  as  an  IBM 
marketing  test  site.) 

•  They  also  support  ISDOS  at  University  of  Michigan  and  feel  PSL/PSA  is 
promising. 

•  FOCUS  and  MARK  IV  are  used  in  CUS. 

•  Pseudo  code  is  used  in  specifications. 

4.        ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

•  INPUT  believes  that  SCE  is  on  the  leading  edge  in  productivity  initiatives. 

Its  strategic  plan  even  incorporates  the  management  of  office  automa- 
tion into  other  user-developed  systems. 

Their  commitment  to  quality  is  apparent  in  the  reported  corporate 
environment. 

End  users  are  deeply  involved,  and  the  plan  is  to  turn  a  substantial 
amount  of  development  over  to  them  on  a  controlled  basis.  (Because  of 
the  budgetary  systems,  there  are  constant  trade-offs  between  purchase 
of  products  or  services,  EDP  department  development,  or  end  user 
development.) 

Management  at  the  highest  levels  is  involved  in  the  systems  develop- 
ment process. 
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Personnel  selection,  training,  and  retention  seem  to  be  good. 

Tools  seem  to  have  been  adapted  to  suit  the  particular  needs  of  the 
company  and  are  under  continuing  review  by  CUS. 

•  Generally  speaking,  SCE  appears  to  have  built  a  solid  "productivity  pyramid" 
from  the  bottom  up.  ~ 

C.       CASE  STUDY  #2  -  THE  SINGER  COMPANY  (SINGER) 

I.  BACKGROUND 

•  Singer  was  a  leader  in  the  establishment  of  an  international  distributed  pro- 
cessing network  in  the  1970s.  This  network  served  as  both  the  means  of 
controlling  data  processing  expense  and  improving  productivity  in  a  highly 
diversified  enterprise. 

•  By  exploiting  the  then  economy  of  scale  of  large  processors.  Singer  was  able 
to  replace  approximately  20  small-  and  mid-range  systems  with  a  large, 
centralized  IBM  data  center  which  served  all  Singer  processing  requirements 
in  the  United  States  and  Europe.  This  resulted  in: 

-   Cutting  the  expense  of  IBM  hardware  by  approximately  60%  over  a  five 
year  period. 

Centralizing  critical  systems  personnel  (systems  programmers, 
analysts,  and  performance  measurement  personnel)  in  a  central  organi- 
zation which  ran  the  network. 


-164- 


INP 


Establishing  central  focus  to  assure  network  and  systems  design, 
including  productivity  improvement  products  and  techniques. 

Minimizing  the  cost  of  programs  products  and  productivity  aids  by 
installing  a  single  copy  on  the  central  facility. 

Centralizing  systems  staff  for  the  development  of  productivity 
improvement  systems  and  applications  systems  (such  as  those  in  manu- 
facturing) which  cut  across  organizational  lines. 

This  central  facility  was  originally  established  in  a  separate  computer  services 
company  which  also  sold  outside  services  and  later  was  brought  under  the 
direct  control  of  a  corporate  vice  president  of  management  information 
systems. 

i 

While  the  Singer  Information  Network  was  justified  by  cost  savings  of  approxi- 
mately $5  million  per  year,  there  was  substantial  pressure  from  the  various 
divisions  to  control  their  own  destinies.  The  fundamental  argument  was  that 
an  operating  division  had  the  right  to  spend  its  money  as  it  saw  fit.  Changes 
in  executive  management  at  Singer  resulted  in  the  decision  to  decentralize 
the  data  processing  function  despite  its  serious  financial  difficulty. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

The  former  central  processing  facility  for  the  network  has  become  the  com- 
puter center  for  a  single  division.  The  center  contains  an  IBM  3033  ond  an 
Amdahl  V6.  At  present  this  installation  has  the  following  expenses  for 
software: 

User  IBM  software  on  the  central  system  costs  $146,172  annually. 
IBM  systems  software  on  the  central  system  costs  $6 1 ,380  annually. 
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OEM  software  on  the  central  system  costs  $84,909  annually. 
Total  expense  for  software  is  $292,461. 

it  is  estimated  that  with  decentralization  $33,670  of  annual  expense 
can  definitely  be  eliminated,  and  $23,064  can  be  eliminated  with  "user 
cooperation."  This  is  a  total  decrease  of  $56,734. 

The  decentralization  effort  which  probably  is  the  culmination  of  intense  IBM 
sales  effort  and  management  pressure  (the  current  chief  executive  officer  of 
Singer  is  an  ex-IBM  employee),  has  resulted  in  the  following  hardware  instal- 
lations throughout  the  United  States  and  Europe. 

Two  434 1  lis. 

Five  4341s. 

Five  4331s. 

A  rough  estimate  of  the  annual  hardware  cost  would  be  $2,235,600  for 
the  decentralized  operation  (not  counting  the  3033  and  Amdahl  V6 
which  will  remain  installed). 

Since  Singer  has  not  had  any  systems  programmers  or  operations  personnel  at 
these  locations  for  nearly  10  years,  the  availability  of  SSX/VSE  will  probably 
be  very  attractive.  The  economics  of  this  will  be: 

One  time  SSX/VSE  license  charges  -  $165,000. 

Annualized  monthly  license  and  support  charge  (SSX/VSE)  -  $187,200. 
Other  IBM  software  support,  estimated  annual  -  $250,000. 


-  166  - 


The  total  annual  software  cost  not  including  the  one  time  charge  will 
be  $437,200  less  the  $56,734  saved  at  the  former  central  site,  or  a  net 
increase  of  $380,466  in  IBM  software  revenue  from  Singer, 

The  cost  of  data  processing  is  obviously  going  up  by  millions  of  dollars  per 
year  at  Singer,  and  the  distraction  of  installing  new  hardware  and  software 
systems  in  the  decentralized  locations  will  divert  systems  personnel  from 
attending  to  the  business  requirements  of  their  users. 

In  the  division  served  by  the  former  centralized  location,  they  are  using  ADRS 
to  assist  users  in  developing  their  own  systems.  However,  because  of  the  cost 
of  decentralization,  the  emphasis  is  naturally  on  cutting  expense  at  that 
location.  The  purchase  of  additional  aids  is  out  of  the  question. 

Assuming  that  management  is  willing  to  pay  the  enormous  price  of  decentrali- 
zation, there  is  definitely  a  need  for  tools  to  determine  (and  monitor)  the  time 
costs  of  decentralization  and  to  measure  the  impact  on  value  added  by  the 
EDP  function  in  support  of  the  business  objectives  of  the  various  organiza- 
tional entities. 

TOOLS  AND  TECHNIQUES  EMPLOYED 

A  substantial  number  of  tools  are  installed  at  the  central  facility.  Among 
them  are: 

VSPC. 

ADRS  (installed  under  user  control). 

A  variety  of  systems  management  facilities. 

MARK  IV. 
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While  centralized,  a  number  of  methodologies  were  explored  for  common  use 
and  standardization.  Since  decentralization,  individual  users  will  probably  not 
be  able  to  cost  justify  any  new  tools  or  techniques  and  probably  will  not  be 
able  to  continue  those  they  employed  at  the  central  location. 

ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

Singer  has  completed  a  180^  change  of  course  from  establishing  strong  cenTrai 
control  of  the  EDP  functions  to  complete  decentralization  of  both  hardware 
and  applications  systems  development.  Users  are  not  only  being  involved, 
they  have  been  given  complete  control  of  their  destinies.  This  can  only  be 
justified  by  the  fact  that  it  should,  at  least  temporarily,  stop  controversy 
between  the  operations  division  and  the  corporate  systems  function. 

Our  assessment  of  the  current  status  of  this  endeavor  is: 

There  is  no  commitment  to  quality. 

End  users  are  being  involved  in  the  wrong  things  (installing  and  running 
hardware). 

Corporate  management  has  decided  that  it  does  not  understand  the 
conflict  between  users  and  the  EDP  function  and  has  decided  to  forget 
about  it.  Division  EDP  management,  on  the  other  hand,  has  decided  it 
is  more  important  to  have  control  of  hardware  than  it  is  to  solve  busi- 
ness problems.  The  focus  of  management  on  both  sides  is  narrowing. 

The  possibilities  of  obtaining  effective  personnel  in  an  additional  12 
locations  is  unlikely. 

The  ability  to  select  the  right  tools  or  afford  them  has  been  seriously 
diminished. 
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•  Singer's  current  situation  is  a  triumph  for  the  arbitrary  installation  of 
hardware  systems  without  regard  for  what  they  will  do  to  benefit  the  business 
objectives  of  the  company.  Only  IBM  will  benefit  from  the  change  of 
direction. 

D.       CASE  STUDY  #3  -  THE  CONTINENTAL  INSURANCE  COMPANIES  (CIC) 

1.  BACKGROUND 

•  CIC  until  this  year  had  a  computer  services  company  which  serviced  both 
external  customers'  and  internal  users'  requirements,^  On  that  basis,  EDP  was 
a  separate  profit  center. 

•  Due  to  tremendous  management  concern  with  white  collar  productivity  and 
the  necessary  role  EDP  must  play  in  productivity  improvement,  the  president 
of  the  company  initiated  a  "User/EDP  Partnership  Study." 

The  major  recommendation  of  that  study  was  that  DP  be  shifted  to  the 
users  where  it  would  become  part  of  regular  company  profit  centers. 

CIC  believes  this  will  establish  an  environment  which  will  improve  the 
productivity  of  both  the  EDP  function  and  the  white  collar  workers. 

There  is  a  productivity  group  under  EDP  and  also  a  separate  produc- 
tivity research  function  within  the  company. 

•  This  emphasis  and  shift  of  responsibility  has  occurred  during  the  past  year. 

2.  EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

•  EDP/user  cooperation  is  the  main  emphasis  as  a  result  of  the  corporate  study 
and  strong  management  support  it  is  receiving.  This  currently  manifests  itself 
in  the  following  ways: 
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Joint  project  teams  under  user  department  project  management  are 
being  encouraged. 

EDP  personnel  are  assigned  to  user  departments  on  a  charge-back 
basis. 

User  departments  are  beginning  to  employ  user  friendly  languages  to  do  \ 
their  own  development  work  against  EDP  provided  data.  (An  informa- 
tion center  has  not  been  established  at  this  point  but  is  being  consid- 
ered.) 

Project  priorities  go  before  a  systems  steering  committee.  Projects 
over  $100,000  are  reviewed  by  the  corporate  president,  and  user/EDP 
maintenance  contracts  are  reviewed  annually. 

1 

It  is  felt  that  EDP  management  is  the  primary  problem  because  of  their 
narrow  technical  focus.  Emphasis  is  being  placed  on  opening  up  communica- 
tion with  users  on  a  continuing  basis.  EDP  is  still  seeking  its  program  role  in 
the  operation  of  the  company. 

Measurement  techniques  are  needed,  and  any  support  for  improving  communi- 
cations and  cross  training  of  EDP  and  user  personnel  would  be  valuable. 

A  separate  Systems  Technology  Group  (50  people)  has  been  established  to 
provide  technical  guidance  to  EDP. 

TOOLS  AND  TECHNIQUES  EMPLOYED 

Users  are  currently  beginning  to  use  RAMIS  and  SAS  to  develop  their  own 
systems  (some  Easytrieve  is  also  being  used)  under  the  general  direction  of  the 
EDP  department. 
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•  Separate  task  forces  have  been  set  up  to  review  Yourdan  methodology,  which 
was  selected  because  it  is  "user  oriented,"  and  the  Policy  Management 
System,  a  major  step  toward  application  software  purchase. 

•  It  is  felt  that  prototyping  is  attractive,  but  C!C  still  has  unanswered  questions 
about  the  ramifications  during  the  systems  life  cycle.  Most  tools  and  tech- 
niques are  rejected  because  systems  and  technical  standards  (quality  assur- 
ance) won't  permit  them  to  be  employed.  ~ 

4.       ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

•  CIC  has  begun  to  build  its  productivity  pyramid  in  an  intelligent  and  reasoned 
manner. 

By  embedding  the  DP  function  into  the  operating  profit  centers  of  the 
business,  operating  management  has  been  given  responsibility  for 
developing  quality  systems. 

The  emphasis  on  end  user  involvement  has  proceeded  in  an  orderly 
fashion,  and  CIC  does  not  seem  inclined  to  rush  into  any  specific  solu- 
tion. 

The  need  for  broadbased  management  is  recongized  (EDP  considers  it 
their  number  one  problem),  and  solutions  are  being  sought. 

The  development  of  effective  personnel  is  related  to  user  involvement 
and  broadbased  management.  At  the  personnel  level  cross  training  and 
assignment  of  EDP  and  operating  personnel  are  stated  objectives. 

The  right  tools  and  techniques  are  being  pursued  on  an  orderly  basis  and 
alternatives  to  internal  development  are  being  seriously  evaluated. 
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•  CIC  has  established  a  productivity  improvement  strategy  and  a  corporate 
environment  which  clearly  aim  at  achieving  value  for  the  enterprise  from  the 
systems  function.  This  strategy  is  being  pursued,  and  while  it  is  still  in  its 
early  stages,  progress  is  being  made. 


E.       CASE  STUDY  //4  -  MCGRAW-HILL  INC.  (MH) 


I.  BACKGROUND 

•  MH  has  given  emphasis  to  the  systems  areas  by  bringing  in  an  almost  entirely 
new  management  team  starting  with  the  Corporate  Senior  Vice  President  of 
Information  Systems  and  Technology  (J.J.  Ryan).  While  the  EDP  organization 
is  somewhat  complex,  it  does  contain  all  of  the  necessary  components  for 
success: 

Normal  operations  and  systems  development  functions. 

A  separate  business  systems  development  function  which  works  with 
users  on  corporation-wide  system  requirements. 

A  separate  systems  assurance  function. 

A  corporate  telecommunications  function  which  includes  data,  voice, 
and  message. 

A  research  and  development  function  which  has  the  following  responsi- 
bilities: 

Advanced  operating  systems  (and  other  systems  software)  re- 
search. 


-  172  - 


INPl 


Decision  support  systems  which  include  the  infornnation  center 
and  evaluation  of  productivity  tools  and  techniques  (especially 
oriented  toward  end  users). 

There  is  a  clear  understanding  that  the  basic  business  of  MH  (publishing)  is 
undergoing  fundamental  changes  because  of  advanced  computer/communica- 
tions technologies.  The  development  of  electronic  information  systems  is  at 
the  heart  of  the  enterprise's  plan  to  adjust  to  a  rapidly  changing  environment. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

The  Corporate  Information  Systems  and  Technology  Department  is  in  the 
process  of  establishing  central  control  over  the  data  processing  facilities 
which  are  still  in  existence  within  the  various  operating  entities  of  MH  (annual 
report  available).  This  is  an  extremely  complicated  political  environment 
because  certain  operating  entities  are  still  decentralized.  (For  example,  DRI 
is  providing  its  information  services  from  Burroughs  equipment.) 

For  the  internal  systems,  the  centralization  effort  is  being  made  through  the 
budgetary  process  and  business  systems  development  which  has  a  project 
evaluation  committee  (which  includes  representatives  of  the  operations  divi- 
sions). The  committee  establishes  priorities  among  a  rolling  90-day  backlog. 
Several  questions  arise  concerning  the  strong  centralization  effort  at  this 
time. 

The  basic  plan  is  to  take  MH  where  Singer  was  five  to  six  years  ago 
(with  improved  technology)  in  terms  of  strong  centralized  hardware  and 
to  exercise  even  more  control  over  application  systems  development. 

While  this  could  conceivably  result  in  substantial  costs  savings,  mini 
and  micro  technology  is  moving  away  from  the  large  centralized  hosts 
being  employed.  The  economies  may  shift  before  the  plan  can  be  put  in 
place. 
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Even  under  the  best  of  circumstances,  a  certain  amount  of  resentment 
occurs  during  centralization  efforts,  and  there  are  indications  that  the 
MH  effort  suffers  from  this  in  several  ways: 

The  Information  Systems  and  Technology  department  is  being 
led  by  "outsiders." 

The  approach  being  taken  may  be  somewhat  heavy-handed. 

The  organizational  entities  within  MH  are  relatively  autonomous 
and  are  being  led  by  rather  strong  individuals. 

Unquestionably  there  is  a  requirement  for  a  broad  and  comprehensive  look  at 
the  information  requirements  of  MH  as  a  company:  their  business  is  informa- 
tion. At  present  IBM  is  "pitching  enterprise  analysis  at  the  highest  levels  in 
the  company." 

At  the  present  time,  the  systems  assurance  function  has  put  together  a 
planning  methodology  which  has  been  published  in  six  volumes.  It 
incorporates  features  of  both  BSP  and  BICS. 

This  methodology  is  being  questioned  even  within  the  Information 
Systems  and  Technology  Department,  and  it  will  unquestionably  be 
difficult  and  expensive  to  implement  (and  enforce). 

A  good  planning  methodology  with  appropriate  software  tools  to  assist  in 
implementation  is  an  obvious  requirement  for  MH.  While  a  thorough  analysis 
of  the  MH  planning  methodology  was  not  possible,  the  impression  was  obtained 
that  they  do  not  yet  have  an  adequate  system. 
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TOOLS  AND  TECHNIQUES  EMPLOYED 


•  The  normal  systems  development  environment,  which  is  key  if  a  highly  cen- 
tralized organization  is  to  succeed,  supports  VM/CMS  and  with  MVS/Wylbur 
running  under  VM. 

9  SAS,  SAS  Graph,  University  of  Waterloo  SCRIPT  (for  the  3800  and  6670), 
DCF,  and  PROFS  are  currently  installed  to  support  systems  development  of 
their  particular  applications  set. 

FOCUS  is  the  primary  tool  employed  for  user  development  activities. 

In  addition,  OPUS,  an  on-line  project  support  system  developed  by  IBM 
Germany  to  "facilitate  the  design,  development,  and  maintenance  of 
software  systems,"  has  been  installed  by  Decision  Support  Systems. 
Documentation  was  obtained,  but  the  system  has  not  been  analyzed.  It 
seemed  promising,  however,  as  described  by  the  interviewee. 

•  The  planning  methodology  previously  described  has  also  been  developed,  but 
the  extent  of  its  use  throughout  the  corporation  has  not  been  determined. 

4.        ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

•  MH  has  many  pieces  of  a  productivity  plan  in  place,  but  the  development  of  a 
well  thought  out  strategy  has  been  delayed  because  of  the  emphasis  on  cor- 
porate hardware/software  control. 

•  At  the  present  time,  the  productivity  pyramid  is  being  viewed  from  the  top. 

The  current  commitment  is  more  to  control  than  quality.  (This  is 
reflected  by  "commitment  to  quality"  being  rated  as  "least  important.") 
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User  involvement  is  being  emphasized  primarily  so  control  can  be 
exercised. 

There  are  indications  that  EDP  management  is  interested  in  the  busi- 
ness objectives  of  the  enterprise,  but  the  Information  Systems  and 
Technology  personnel  would  still  prefer  to  keep  operating  management 
dependent  upon  them  as  "experts." 

Effective  personnel  (recruitment,  training,  and  retention  of  "good 
people")  is  viewed  as  the  primary  productivity  bottle-neck,  and  em- 
phasis is  high  in  this  regard.  Unfortunately,  the  emphasis  is  on  personal 
loyalty  to  the  EDP  organization. 

The  analysis  of  tools  and  aids  is  stated  to  be  a  primary  problem  with 
productivity,  and  the  selection  of  OPUS  is  interesting  for  the  following 
reasons: 

It  was  selected  while  IBM  is  still  deciding  whether  to  support  it 
in  the  United  States.  (The  director  who  selected  it  has  the 
advantage  of  being  able  to  translate  German  -  which  adds  to 
control  of  the  system.) 

The  statement  was  made:  "We  think  it  is  best  and  we  will  install 
and  see  what  happens." 

•  in  some  ways,  MH  is  attempting  to  build  the  pyramid  from  the  top  down. 
However,  many  of  the  things  being  done  are  probably  right,  it  is  our  opinion 
that  a  great  deal  of  internal  energy  will  be  wasted  in  the  struggle  for  control 
while  the  needs  of  the  business  will  suffer. 
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CASE  STUDY  #5  -  UNIVERSITY  OF  NORTH  CAROLINA  (UNC) 


I.  BACKGROUND 

•         It  is  necessary  to  explain  why  UNC  was  chosen  as  an  interview  site,  and  there 
are  several  reasons: 

Dr.  Frederick  P.  Brooks,  Jr.,  Chairman  of  the  Computer  Sciences 
Department,  was  interviewed  over  the  telephone  because  of  his 
interest  in  software  engineering  and  his  role  in  the  development  of 
System/360  hardware  and  the  original  OS/360  software. 

The  INPUT  productivity  study  had  Stanford  University  as  a  client,  and 
the  unique  problems  of  university  EDP  departments  serve  to  illustrate 
some  of  the  problems  in  improving  productivity  in  the  development  of 
commercial  systems. 

It  was  learned  that  UNC  was  in  the  process  of  converting  from  a 
Univac  90/80  to  an  IBM  4341-1  I .  This  was  of  interest  for  two  reasons: 

It  was  an  opportunity  to  obtain  the  opinions  of  experienced  data 
processing  personnel  who  were  first-time  users  of  IBM  hard- 
ware/software systems.  And  the  conversion  process  itself  was 
of  interest. 

The  other  companies  being  interviewed  have  multiple,  large- 
scale  IBM  systems  installed  and  have  had  substantial  experiences 
with  IBM  systems.  IBM's  approach  to  the  first-time  user  of  a 
43XX  system  was  deemed  important. 

Both  the  Director  of  Administrative  Data  Processing  (ADP)  and 
the  Manager  of  Systems  Development  had  worked  for  IBM 
competitors  (RCA  and  NCR  respectively). 
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ADP  has  responsibility  for  the  administrative  data  processing  of  the  univer- 
sity, including  the  hospital.  Timesharing,  large-scale  computing,  and  outside 
data  bases  are  available  through  the  Research  Triangle  Computer  Center 
which  was  established  by  Dr.  Brooks  in  the  late  1960s. 

While  the  Director  of  ADP  is  a  lecturer  In  the  Computer  Sciences 
Department,  the  problems  associated  with  administrative  data  process- 
ing are  not  considered  to  be  of  sufficient  challenge  to"  warrant  very 
much  attention  from  the  academic  side  of  computer  sciences. 

In  fact,  when  Dr.  Brooks  addresses  software  engineering,  his  frame  of 
reference  is  the  large-scale  systems  project  (not  quite  OS/360  propor- 
tions necessarily,  but  large).  It  is  our  opinion  that  this  problem  has 
plagued  those  who  develop  the  systems  software  which  must  be  used  by 
EDP  departments.  Specifically: 

Commercial  applications  systems  are  categorized  as  rather 
trivial  in  nature  (as  they  are  from  a  computational  point  of 
view). 

.  The  human  interface  which  may  be  easy  to  use  for  computation 
by  the  computer  scientist  is  not  necessarily  simple  when  exposed 
to  commercial  problems  requiring  massive  data  handling  and 
manipulation  rather  than  computing  explicit  (if  complex) 
algorithms. 

Therefore,  crude  administrative  data  processing  facilities  frequently  exist  in 
proximity  to  computer  scientists  responsible  for  the  design  of  advanced  hard- 
ware/software systems  concepts  with  very  little  communication,  much  less 
understanding,  between  the  two. 
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Thus,  when  the  Governor  of  North  Carolina  expressed  concern  about  produc- 
tivity and  established  a  council  to  see  what  could  be  done,  it  was  considered  a 
problem  for  ADP  even  though  only  2%  of  the  budget  was  spent  on  data 
processing  compared  to  3%  to  5%  in  other  states.  Improving  productivity 
essentially  meant  keeping  costs  down. 

It  was  in  this  setting  that  IBM  was  able  to  sell  the  4341-1  I  (which  was  con- 
sidered competitive  with  Univac  by  ADP)  based  on  the  broad  range  of  appilca- 
tions  packages  available  for  the  system.  The  availability  of  this  software  was 
the  deciding  factor  in  the  selection. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

UNC  had  a  10-day  plan  to  install  the  4341 .  Getting  the  system  up  and  running 
actually  took  three  months.  The  primary  problem  was  software;  the  hardware 
is  highly  regarded  having  never  been  down  in  nine  months. 

This  difficulty  in  bringing  up  an  MVS/TSO/CICS  system  with  experi- 
enced systems  personnel  illustrates  all  too  clearly  the  reason  IBM  is 
pushing  preconfigured  systems  for  the  uninitiated. 

IBM  could  have  lost  $30,000  to  $40,000  in  revenue  plus  the  systems 
support  they  provided  if  the  system  had  been  leased.  In  addition,  the 
IBM  sales  force  is  measured  on  prompt  installation  of  systems.  IBM 
branch  managers  do  not  want  systems  labeled  "shipped  but  unbilled." 

But  the  user,  meanwhile,  is  spending  his  time  fighting  a  complicated 
software  system  which  does  not  let  him  concentrate  on  his  own  prob- 
lems. 

In  the  university  environment,  many  users  consider  themselves  sophisticated 
and  want  to  do  their  own  work.  However,  end  user  involvement  at  the  present 
time  takes  place  through  a  traditional  systems  and  procedures  function  which 
includes  both  user  and  ADP  representatives. 


-  179  - 


INPUT 


The  requirements  for  the  "automated"  portion  of  the  resulting  system 
are  presented  to  ADP  for  implementation. 

Depending  on  the  nature  of  the  overall  system,  someone  from  S  &  P 
may  be  the  project  leader  for  implementation. 

At  the  present  time,  users  do  not  even  have  tools  for  screen  design 
(although  ADP  recognizes  this  will  be  necessary). 

•  The  productivity  problem  at  UNC  is  defined  in  terms  of  increased  demand  and 
the  inability  of  ADP  to  respond. 

3.        TOOLS  AND  TECHNIQUES  EMPLOYED 

•  Systems  today  are  essentially  being  developed  the  way  they  were  20  years  ago 
except  that  terminals  are  now  being  used  for  programming. 

•  The  Director  of  ADP  (who  Is  a  knowledgeable  and  respected  professional  in 
the  data  processing  industry)  attends  professional  meetings  and  reads  tech- 
nical publications.  He  has  not  been  impressed  with  the  activity  taking  place 
in  structured  methodologies,  feeling  that  good  systems  design  (an  analysis) 
naturally  leads  to  the  proper  degree  of  "structuring." 

•  The  general  attitude  about  tools  and  aids  is  that  they  are  being  emphasized 
because  there  is  at  least  hope  that  the  results  of  the  systems  development 
effort  can  be  measured.  ADP  management  at  UNC  seems  to  feel  that  com- 
pliance with  standards  and  the  constraints  of  various  methodologies  tend  to 
become  de  facto  measures  of  productivity,  regardless  of  whether  their  true 
impact  is  positive  or  negative.  They  suspect  that  in  most  cases  it  may  be 
negative. 
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ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

One  comes  away  from  UNC  with  the  feeling  that  someone  turned  the  clock 
back  15  years.  The  initial  assessment  would  be  that  they  have  not  taken  any 
initiatives.  But  viewed  in  the  broader  perspective  of  the  productivity  pyra- 
mid, they  may  actually  be  better  off  than  organizations  where  a  great  deal  of 
frantic  effort  has  taken  place  -  at  least  they  have  not  thrown  money  and 
technical  talent  at  the  problem  and  failed,  ~ 

There  is  a  commitment  to  quality  on  the  part  of  the  ADP  department, 
and  they  do  have  a  comprehensive  systems  development  plan.  (A  copy 
of  which  was  acquired.) 

Users  are  being  involved  in  the  important  aspects  of  the  systems  life 
cycle  (requirements,  definition,  analysis,  and  design).  In  fact,  it  ap- 
pears there  is  a  good  understanding  within  the  ADP  department  that  all 
systems  and  procedures  do  not  necessarily  lend  themselves  to  automa- 
tion. The  fact  that  users  have  not  been  involved  in  programming  is  not 
necessarily  bad;  it  means  their  efforts  have  been  confined  to  the  more 
important  portion  of  the  life  cycle. 

ADP  seems  to  have  a  clear  understanding  of  their  business  objectives 
and  problems,  and  user  management  seems  to  have  an  understanding  of 
what  computer  systems  should  and  should  not  be  used  for. 

The  primary  concern  at  the  present  time  is  effective  personnel  where 
the  constraints  of  mandated  salary  schedules  and  the  proximity  of  the 
Research  Triangle  make  recruitment  and  retention  of  good  employees 
extremely  difficult. 

The  fact  that  they  have  not  acquired  tools  may  be  wise.  Perhaps  they 
are  building  their  pyramid  with  the  materials  at  hand,  with  their  re- 
sources more  profitably  applied  to  the  foundation. 
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•  UNC  has  probably  made  more  productive  use  of  their  resources  than  most 
organizations  on  the  leading  edge  of  productivity  improvement  techniques  and 
methods.  The  fact  that  they  are  now  concentrating  on  alternatives  to  internal 
development  (purchase  of  packages)  is  also  probably  the  right  decision  at  the 
right  time. 

G.       CASE  STUDY  #6  -  THE  CITIZENS  AND  SOUTHERN  BANK  (C  &  S) 
I.  BACKGROUND 

•  Until  four  years  ago,  C  &  5  spent  most  of  its  time  and  resources  following 
hardware  and  operating  systems  changes  initiated  by  IBM.  This  was  done  by 
ignoring  obsolete  applications.  (The  fact  that  they  were  written  in  autocoder 
indicates  the  magnitude  of  the  problem.) 

•  Within  the  last  four  years,  C  &  S  has  concentrated  on  upgrading  their  appli- 
cations systems  and  in  building  a  delivery  system  (computer/communications 
network)  to  facilitate  the  automation  of  their  branch  offices.  This  is  being 
done  under  corporate  direction  of  a  productivity  steering  committee  with  the 
following  objectives: 

Number  one,  to  automate  customer  services  (essentially  improve 
productivity  at  the  branch  level). 

Number  two,  to  expand  geographically  without  enormous  startup 
costs.  (This  implies  electronic  banking.) 

•  The  emphasis  on  the  computer/communications  network  has  concentrated 
attention  on  central  applications  development  problems  to  the  degree  that  the 
function  is  currently  viewed  as  a  necessary  evil. 
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EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 


•  The  current  direction  at  C  &  S  is  to  provide  accurate  evaluation  of  systems 
effectiveness  in  terms  of  operational  costs. 

The  conclusion  has  been  reached  that  EDP  systems  develoDment 
departments  (with  the  encouragement  of  vendors)  have  pursued  a  poficy 
of  cost  justification  for  electronic  systems  which  ignores  the  opera- 
tional costs.  This  results  in  the  followina: 

An  electronic  system  may  be  justified  and  still  not  be  the  right 
answer  in  terms  of  overall  cost  effectiveness. 

Starting  with  cost  justification  as  an  objective,  you  are  inclined 
to  ignore  maintenance  and  enhancement,  which  represent  life 
cycle  costs  of  approximately  5:1  over  development  costs. 

•  This  has  led  to  a  philosophy  which  identifies  the  EDP  development  function  as 
the  primary  bottleneck  in  achieving  productivity  (by  their  definition).  The 
interviewee  (Vice  President  of  Operations)  has  concluded  that  low  produc- 
tivity in  development  cannot  be  improved  significantly  since  it  is  the 
problem.  Therefore  the  answer  is: 

Eliminate  the  function  through  higher  level  languages  for  users  and  the 
purchase  of  applications  systems. 

He  cited  the  experience  of  the  aerospace  industry  where  only  6%  of  the 
programming  was  done  by  the  data  processing  function  and  predicts  a 
comparable  "explosion"  of  user-developed  systems  in  the  1980s. 

•  Essentially,  C  &  S  has  jumped  to  the  conclusion  that  things  are  not  going  to 
improve  in  conventional  systems  development  and  that  the  EDP  development 
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function  is  going  to  be  severely  reduced  or  eliminated.  If  one  starts  with  this 
assumption,  it  is  possible  to  establish  an  objective  of  transferring  responsi- 
bility away  from  the  EDP  department.  This  conceivably  could  save  substan- 
tial amounts  of  time,  effort,  and  expense  in  trying  to  improve  EDP  produc- 
tivity. 

The  conclusions  reached  above  are  those  of  the  interviewee.  There  is  no 
indication  of  an  approved  strategy  with  the  objective  of  severely  reducing  the 
requirement  for  internal  development  of  systems  in  the  EDP  department.  If 
this  is  the  objective  of  C  &  S,  decisions  must  be  made  on  appropriate  tools  to 
achieve  their  objectives. 

TOOLS  AND  TECHNIQUES  EMPLOYED 

The  primary  technique  to  improve  productivity  has  been  to  purchase  packaged 
software. 

Fifteen  major  programs  have  already  been  purchased,  the  longest  one 
being  a  Personal  Trust  System  at  a  cost  of  $250,000. 

It  is  projected  that  a  financial  transaction  processing  system  will  soon 
be  available  for  purchase  (Anacomp  being  the  probable  vendor).  Once 
that  occurs,  C  &  S  projects  they  could  eliminate  the  in-house  systems 
development  of  commercial  banking  systems. 

It  is  felt  that  the  development  of  higher  level  languages  is  encouraging,  and 
the  proper  user  friendly  interface  will  appear  in  the  1980s.  At  that  point,  the 
user  S  &  P  function  will  completely  bypass  the  EDP  systems  development 
process.  Current  emphasis  is  on  RAMIS  and  FOCUS,  and  they  are  felt  to  be  a 
big  step  in  the  right  direction. 


-  184  - 


ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 


Banking  in  general  has  been  forced  to  address  issues  of  productivity  and 
changing  technology  in  order  to  rennain  competitive.  Automated  systems  are 
viewed  as  the  primary  instrument  of  competitive  change.  This  has  prompted 
C  &  S  to  establish  a  primary  business  objective  of  automating  their  branch 
offices. 

In  order  to  achieve  its  objective,  C  &  S  is  committed  to: 

Quality  systems  which  will  demonstrate  high  reliability  and  aim  at 
100%  availability  of  hardware  and  software.  This  will  be  done  with  the 
understanding  that  only  a  quality  service  delivery  system  will  be  an 
asset  in  the  competitive  market  for  banking  services. 

i 

Placing  end  users  in  a  leading  position  in  the  systems  development 
process,  and  not  merely  involving  them.  Branch  managers  wiii  be 
involved  in  the  day-to-day  operation  of  the  system;  they  are  auto- 
matically involved. 

Management,  both  corporate  and  information  services,  recognizing  that 
success  in  the  banking  business  is  highly  dependent  upon 
computer/communications  networks.  There  is  no  room  on  either  side 
for  someone  who  would  prefer  to  ignore  what  is  happening  on  the  other 
side. 

Deciding  that  the  lack  of  effective  personnel  (management  and  pro- 
grammer/analysts) in  the  EDP  systems  function  is  the  problem.  The 
answer  is  to  reduce  the  dependence  on  the  function. 

Little  emphasis  is  being  placed  on  how  to  fix  the  EDP  productivity 
problems  by  applying  tools  and  techniques.  C  &  S  is  waiting  to  put  the 
tools  in  the  hands  of  the  users. 
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•  C  &  S  believes  there  will  always  be  a  need  for  good  systems  people  (after  ail, 
.  banking  is  dependent  on  good  systems).    They  would  be  happy  to  see  those 

people  coming  from  the  EDP  area,  but  this  has  not  happened.  Therefore,  the 
bank  has  adopted  an  approach  to  eliminate  (or  at  least  decrease  dependence 
upon)  the  EDP  bottleneck  to  systems  development.  In  the  banking  industry 
this  is  probably  a  wise  decision  at  this  time. 

H.  CASE  STUDY  #7  -  SOUTHERN  RAILWAY  (NS) 

I.  BACKGROUND 

•  Southern  Railway  is  in  the  process  of  consolidating  with  Norfolk  and  ¥/estern 
Railroad,  but  the  EDP  departments  remain  separate  under  the  corporate 
leadership  of  Mr.  J.  L.  Jones,  Vice  President  of  Management  Information 
Systems.  Jack  Jones  formerly  headed  MIS  at  Southern  Railway  and  is  a  com- 
puter industry  pioneer,  having  been  a  prominent  figure  in  establishing  COBOL 
as  a  language  while  he  was  with  the  U.S.  Air  Force. 

•  Southern  Railway  is  somewhat  unique  in  the  stability  of  its  EDP 
management.  Most  have  been  with  the  company  for  over  20  years,  having 
come  to  Southern  directly  from  college.  Many  American  companies  consider 
themselves  fortunate  if  data  processing  personnel  remain  for  three  to  four 
years. 

•  Southern  has  been  on  the  leading  edge  of  data  processing  in  several  regards: 

it  was  a  test  site  for  punch  card  equipment  for  Computing-Tabufating- 
Recording  Corporation  which  eventually  became  IBM  with  Southern 
Railway  as  one  of  its  first  major  customers. 
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It  established  a  COBOL  standard  at  a  time  when  the  language  had  little 
use  outside  the  federal  government. 

It  installed  prototypes  of  early  IBM  terminal  equipment  (1050s),  and 
became  a  leader  in  teleprocessing,  using  what  at  that  time  was  the 
largest  private  microwave  network  in  the  United  States. 

It  became  a  leader  in  distributed  processing  using  Data  General  mini- 
computing.  - 

It  became  an  early  advocate  of  on-line  programming  using  TSO  and  has 
advocated  "paperless  programming." 

•  Southern  is  also  unusual  in  establishing  an  MIS  organization  with  corporate 
responsibility  for  both  industrial  engineering  and  operations  research. 

•  The  company  has  long  prided  itself  on  being  innovative  and  highly  productive 
in  all  its  operations  from  its  early  use  of  radio  switching  and  automated 
railroad  yards  to  its  application  of  computer  technology  to  operating  problems 
(as  opposed  to  routine  accounting  functions). 

2.       EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

•  Southern  has  designed  its  own  network  architecture  which  permits  it  to 
control  car  location  and  movement  control,  waybill  processing,  scheduling  of 
maintenance  and  car  repair,  and  a  variety  of  other  functions.  These  functions 
have  been  operational  for  some  time  and  the  challenges  are  always  to  improve 
reliability.  The  railroad  cannot  operate  without  its  computer  systems. 

•  With  the  major  systems  installed,  problems  of  productivity  are  currently 
concentrated  in  two  critical  areas: 
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There  is  a  growing  need  for  office  automation  systems.  This  places 
heavy  demands  on  available  systems  personnel  in  areas  they  are 
unfamiliar  with  (or  interested  in  -  many  managers  have  industrial 
engineering  backgrounds). 

The  IBM  operating  systems  are  being  driven  to  the  limit  of  their 
function  and  capacity.  This  means  the  installed  systems  are  extremely 
complex  and  subject  to  performance  degradation  as  new  applications 
are  added  (or  new  systems  connected  to  the  network).  This  results  in: 

Having  to  understand  what  can  and  cannot  be  done  with  the 
extremely  complex  interaction  of  the  installed  hardware/soft- 
ware systems. 

Never  knowing  when  a  given  hardware/software  change  will 
cause  intolerable  performance  problems.  For  example,  the  8100 
was  tried  and  the  performance  could  not  be  tolerated,  and  SPF 
cannot  be  used  because  it  degrades  performance  to  an  unaccept- 
able degree. 

Having  to  expend  a  great  deal  of  effort  in  dealing  with  the 
necessary  standards  and  restrictions  required  to  maintain  the 
operational  viability  of  the  existing  systems  complex  rather  than 
solving  the  business  problems. 

•  Southern  has  and  will  continue  to  place  a  great  deal  of  reliance  on  individual 
capability  and  ingenuity.  This  has  stood  them  in  good  stead,  but  currently 
there  are  some  problems  associated  with  it: 

Outstanding  personnel  do  not  like  to  work  in  the  development  environ- 
ment described  above. 
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Some  of  the  problems  of  office  automation  do  not  require  outstanding 
personnel. 

Management  personnel  is  frustrated  with  budgeting  project  teams  to 
accomplish  what  they  think  should  be  done  by  a  single  outstanding 
individual. 

Project  management  and  development  methodologies  are  being^re- 
jected  because  "methodologies  and  structuring  will  drive  good  people 
away." 

The  reaction  to  new  tools  and  techniques  is  that  they  will  be  investi- 
gated but  they  usually  seem  to  be  more  trouble  than  they  are  worth. 

Current  expressed  needs,  in  addition  to  keeping  good  personnel  invoh/ed  in 
implementation  rather  than  making  them  managers,  is  to  get  end  users  in- 
volved in  the  implementation  phase  as  well  as  in  early  development. 

TOOLS  AND  TECHNIQUES  EMPLOYED 

As  mentioned,  Southern  was  a  leader  in  on-line  programming,  and  they  have 
made  extensive  use  of  TSO  for  over  10  years.  They  have  established  a 
development  environment  which  is  essentially  paperless  (there  are  no  cards  or 
listings). 

They  do  not  believe  in  structured  methodologies  for  the  reasons  expressed 
above. 

BSP  and  enterprise  planning  promoted  by  IBM  has  been  presented  to  them,  but 
Jack  Jones  does  not  believe  in  that  level  of  planning.  Jones  feels  the  environ- 
ment changes  more  rapidly  than  you  can  plan  for  it. 
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ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 


Southern  Railway  is  characterized  as  an  organization  with  a  reputation  for 
solving  problems.  They  expect  high  productivity  from  their  employees  and  a 
commitment  to  the  company,  which  is  unusual  in  American  industry  today. 
(Just  before  the  interview  the  union  employees  went  out  on  strike,  and  MIS 
management  employees  not  only  ran  the  network,  but  the  A.V.P.  of  MIS  went 
out  and  switched  cars  in  a  yard.) 

In  terms  of  the  productivity  pyramid,  they  can  be  assessed  as  follows: 

The  commitment  and  even  tradition  of  quality  systems  to  provide 
service  to  their  customers  has  been  the  established  environment  for 
these  EDP  employees  throughout  their  careers. 

User  involvement  has  also  been  an  established  fact  for  over  20  years. 
The  Operating  Vice  President  of  the  railroad  insisted  on  having  his  own 
computer  group  (separate  from  accounting)  in  the  1950s.  The  sole 
purpose  was  to  work  directly  with  operating  personnel.  This  group 
currently  controls  all  MIS  functions. 

The  fact  that  both  industrial  engineering  and  operations  research  come 
under  the  MIS  function  is  the  best  indication  that  broadbased  manage- 
ment perspective  has  been  emphasized. 

Effective  personnel  is  a  continuing  concern.  Current  attention  is  being 
focused  on  quality  people  because  the  development  and  applications 
environment  has  changed.  There  is  a  good  track  record  of  attracting 
and  keeping  the  right  people. 

The  tools  and  techniques  necessary  to  provide  a  productive  environ- 
ment will  be  applied,  but  at  present  many  being  promoted  do  not  seem 
to  contribute  in  Southern's  environment. 
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•  Generally  speaking,  Southern  has  maintained  a  productive  environment 
through  good  management  at  both  the  corporate  and  MIS  levels.  While  there 
is  concern  about  why  it  takes  much  longer  to  do  things  today  than  it  did  in  the 
old  days,  it  is  primarily  a  sign  that  there  is  not  any  complacency.  However, 
there  is  one  problem  which  will  require  attention. 

Once  large,  complex,  communications-oriented  systems  are  in  place, 
they  begin  to  dictate  the  environment  and  are  difficult  to  change. 
(IBM's  internal  Advanced  Administration  System  may  be  an  example  of 
a  system  which  will  be  enhanced  and  maintained  forever  without  ever 
being  replaced.) 

The  evolution  of  IBM's  operating  systems  and  other  systems  software 
(now  including  "productivity  aids")  was  not  really  designed  to  operate  in 
in  its  present  environment.  The  operating  system  has  continued  to 
function  with  bigger  and  bigger  engines  to  drive  it. 

Where  the  user  has  extended  the  functional  use  of  the  system  to  its 
maximum,  it  reaches  its  limit  before  IBM  is  prepared  to  provide  the 
necessary  software  improvements  or  the  next  hardware  upgrade.  (IBM 
does  not  expect  the  user  to  be  doing  much  except  running  the  operating 
system  itself.) 

For  example.  Southern  attempted  to  use  SPF  on  the  3033  used 
for  development,  and  it  reported,  "We  can't  afford  it,  60  users 
brought  the  3033  to  its  knees."  This  would  represent  an  invest- 
ment of  well  over  $100,000  to  support  each  programmer. 

Southern  also  ruled  out  the  use  of  the  IBM  8100  as  a  distributed 
engine  because  of  poor  performance.  (Southern  has  nearly  500 
Data  General  minis  and  micros  installed.)  This  could  affect  not 
only  any  attempt  Southern  might  make  to  go  to  an  SNA  environ- 
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ment,  but  also  must  influence  their  approach  to  office  automa- 
tion. 

What  this  means  is  that  Southern  must  consider  the  future  of  its  highly 
centralized  data  bases  (it  currently  has  sixty-eight  3350s  plus  an  IBM 
3850  mass  storage  system).  This  could  dictate  analysis  and  planning  of 
the  information  resource  regardless  of  Southern's  distaste  for  such 
long-range  planning.  Attempting  to  maintain  the  current  architecture 
may  be  entirely  too  expensive  based  on  its  impact  on  -personnel  and 
financial  resources. 
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VII    SOFTWARE   APPROACH   BY  LEADING 

SOFTWARE  VENDORS 


VII 


SOFTWARE  APPROACH  BY  LEADING  SOFTWARE  VENDORS 


A.       SUMMARY  AND  ANALYSIS 


•  The  development  of  high  quality  generalized  software  is  necessary  if  software 
vendors  are  to  remain  in  business.  Based  on  the  interviewed  companies,  two 
conclusions  can  be  reached: 

Selecting  and  retaining  high  quality  personnel  is  critical  not  only  to 
having  a  productive  organization,  but  to  be  producing  a  quality  product 
at  all. 

No  particular  tools,  aids,  and  techniques  are  employed  in  the  develop- 
ment process.  The  selection  of  the  development  environment  is  nor- 
mally left  up  to  the  particular  product  manager  or  project  leader. 

•  These  findings  confirm  INPUT'S  previous  productivity  research.  On  large 
projects  or  those  requiring  a  high  quality  product  (system),  development 
environments  are  normally  not  dictated  but  are  left  up  to  the  particular 
project  leader.  Two  examples  from  this  past  research  are: 

A  systems  development  company  which  is  widely  publicized  as  having 
standardized  techniques  for  producing  software  was  found  to  be  ex- 
tremely flexible  on  a  project-by-project  basis.  The  Vice  President  of 
Software  Engineering  frankly  admitted,  "Let's  face  it,  if  I  could  be  '0% 
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more  effective  on  these  large  government  projects,  no  one  else  could 
compete  against  us." 

An  aerospace  company  spent  over  $1  million  tailoring  a  programmers' 
workbench  which  was  to  become  the  corporate  standard  on  all  future 
projects.  The  reaction  of  a  project  leader  was: 

"Oh,  that  doesn't  bother  me.  I  have  my  own  development  sysfem 
which  is  better,  and  my  project  has  another  three  years  to  run." 

"By  that  time,  they  will  have  forgotten  about  a  corporate 
standard;  project  leaders  can't  be  held  responsible  if  they  can't 
have  the  tools  they  need  (want)." 

•  Our  conclusion  is  that  software  is  not  being  engineered  even  in  the  environ- 
ments where  this  would  seem  most  appropriate  and  even  necessary.  The 
reasons  for  this  seem  clear: 

Different  projects  have  different  requirements  for  tools  and  tech- 
niques. At  present,  particular  tools  and  techniques  are  advocated  as 
general  solutions  to  all  problems.  This  is  no  more  appropriate  than 
saying  a  single  type  motor  vehicle  is  best  for  transporting  any  number 
of  people  any  distance. 

Particular  people  are  so  crucial  to  project  success  that  the  risk  of 
standardization  of  approach  is  greater  than  permitting  the  proven  high 
performer  to  perform.  This  implies: 

We  still  do  not  know  what  constitutes  productivity  in  the 
systems  development  process.  ("I  don't  know  how  he  does  it,  but 
he  always  brings  in  his  projects  on  time.") 


-  194  - 


INPU 


There  is  no  science  in  managing  systems  development  at  the 
present  time. 

•  For  this  reason,  our  interviews  were  selected  to  obtain  a  variety  of  ap- 
proaches to  solving  the  productivity  problems  of  software  vendors'  customers, 
as  well  as  concentrating  on  how  they  produce  their  "solutions." 

B.       SOFTWARE  VENDOR  CASE  STUDY  #  I  -  MATHEMATICA  PRODUCTS 
GROUP  (MPG) 

I.  BACKGROUND 

•  Conceptually,  RAMIS  started  as  a  tool  for  "information  retrieval"  before  the 
days  when  "management  information  systems"  and  "data  base  management 
systems"  became  popular  terminology.  IBM  had  an  inverted  file  system,  which 
was  developed  for  internal  use  and  never  released  as  a  product.  It  was  prac- 
tically identical  to  the  original  RAMIS  (this  was  15  years  ago). 

•  RAMIS  II  has  evolved  to  include  considerably  more  capability,  and  "fourth 
generation  languages"  have  finally  been  discovered  by  some  DP  managers  and 
consultants.  They  are  really  the  evolutionary  product  of  report  generators 
and  relatively  crude  data  structuring  techniques  which  were  developed  by 
commercial  data  processing  users  many  years  ago.  They  have  achieved  their 
current  popularity  for  several  reasons: 

They  do  permit  programmer /analysts  to  develop  systems  more  rapidly. 

They  are  user  friendly  in  that  they  permit  end  users  to  develop  their 
own  reports. 

They  are  the  best  tools  currently  available  for  prototyping. 


-  195  - 


INPUT 


However,  the  current  enthusiasm  for  fourth  generation  languages  should  be 
tempered  by  the  statement  of  an  IBM  employee  concerning  the  internal  IBM 
systems  comparable  to  RAMIS:  "Anyone  who  thinks  MIS/360  is  going  to  solve 
all  the  world's  problems  doesn't  understand  the  problem." 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

RAMIS  II  is  currently  used  for  the  development  of  all  of  MathematFca's 
administrative  data  processing  applications  except  corporate  receivables. 
MPG's  definition  of  a  "fourth  generation  system"  is  as  follows  (a  detailed 
paper  on  the  subject  is  available): 

There  is  a  DBMS  such  as  Easytrieve. 

There  is  a  nonprocedural  reporter. 

There  is  nonprocedural  update  capability. 

There  is  an  executive  or  command  language. 

The  method  of  systems  development  which  is  recommended  using  RAMIS  II  is 
as  follows: 

Develop  program  modules  for  the  following: 

Update  (on-line  or  batch). 

Report  preparation. 

Processing  or  manipulation. 
Provide  list  of  executive  routines  for  RAMIS  II. 
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Determine  implementary  experience  on  ti^e  functional  module  level. 

Assign  personnel  and  make  estimate  of  project  time.  (Modules  average 
two  man-days  of  effort,  and  the  largest  must  be  restricted  to  10  days.) 

Establish  schedules  and  monitor. 

Reported  improvements  for  RAMIS  II  over  conventional  development  are  5:1 
(RAMIS  II  takes  one-fifth  the  time).  This  improvement  is  based  primarily  on 
improvements  in  the  design  and  programming  phases  of  the  systems  life  cycle, 
although  improvement  is  also  claimed  in  data  analysis,  testing,  and  mainte- 
nance. The  stated  needs  are  for  a  "fifth  generation  language"  which  would 
assist  in  problem  definition  and  analysis. 

It  is  believed  that  the  fourth  generation  systems  approach  can  effect  substan- 
tial productivity  improvements  on  a  significant  number  of  commercial 
systems. 

On  the  product  development  side  RAMIS  II  is  written  in  Assembly  language 
because  of  performance  requirements.  This  indicates  the  following: 

Productivity  is  limited  by  the  development  language  as  are  the 
methodologies  which  can  be  employed. 

Development  of  systems  in  Assembly  language  is  even  more  people 
dependent  than  systems  written  in  higher  level  languages. 

There  is  a  need  for  a  commercially  available,  higher  level  programming 
language  for  developing  other  higher  level  languages.  The  primary 
design  point  of  this  language  (other  than  ease  of  use  for  systems  pro- 
grammers) would  be  object  program  efficiency. 
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It  is  important  to  point  out  that  "fourth  generation  systems"  is  used  to 
describe  a  technique  of  systems  development  in  which  a  tool  (fourth  genera- 
tion language)  is  employed.  This  packaging  of  tools,  while  not  unique,  is 
highly  desirable. 

The  lack  of  tools  for  building  tools  has  been  a  classic  oroblem  for  a  numbeF'of 
years.  IBM  attempted  writing  systems  using  PL/!  and  actually  atternpted  a 
FORTRAN  compiler  written  in  FORTRAN.  However,  they  finally  had  to  both 
subset  and  extend  PL/I  to  build  a  tool  for  writing  systems  software,  and  there 
is  great  suspicion  that  the  tool  may  be  at  the  heart  of  certain  of  the  per- 
formance problems  associated  with  IBM's  system  software. 

It  is  obvious  that  Mathematica  believes  developing  a  higher  level  language 
compiler  for  writing  RAMIS  would  either  be  too  difficult  or  too  costly.  This 
may  be  shortsighted. 

ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

Mathematica's  use  (and  recommended  use)  of  RAMIS  II  as  a  tool  embedded  in 
a  methodology  is  good,  and  it  may  represent  a  breakthrough.  In  fact  the 
picture  presented  to  INPUT  by  Mathematica  does  not  tell  the  full  story,  and 
INPUT  feels  it  should  more  properly  be  represented  as  in  Exhibit  Vll-I. 

Most  structured  methodologies  not  only  do  not  improve  on  productivity 
compared  with  classic  systems  development  techniques,  but  they 
actually  have  an  adverse  impact  on  smaller  systems. 

While  the  exact  point  of  adverse  impact  is  not  known,  it  is 
probably  higher  than  the  one  man-year  frequently  used  as  a  rule 
of  thumb  for  mandating  structure  methodologies. 
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EXHIBIT  Vll-1 


SYSTEMS  DEVELOPMENT  APPROACHES 
(COST  AND  SIZE  RELATIONSHIPS) 


Systems  or  Project  Size 
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Research  on  this  subject  is  limited  and  should  be  pursued. 


The  fourth  generation  systems  approach  would  seem  to  provide  even 
more  benefit  on  the  smaller  projects  than  indicated,  but  benefits 
probably  decrease  (costs  increase)  more  sharply  on  larger  projects. 
Additional  research  on  this  would  also  be  desirable. 

•  As  far  as  a  high  level  language  for  developing  tools  is  concerned,  the  following 
observations  (partially  supported  by  past  experience  if  not  -research)  are 
considered  important: 

There  is  no  reason  a  good  applications  language  cannot  also  be  used  for 
writing  systems  software.  (Therefore,  compilers  and  systems  could  be 
written  in  their  own  language.) 

While  it  is  always  theoretically  possible  for  a  programmer  to  write 
more  efficient  code  in  Assembly  language  than  a  higher  level  language 
compiler  can  generate,  this  normally  does  not  occur  with  a  compiler 
(and  language)  optimized  to  produce  efficient  code. 

Not  enough  attention  has  been  given  to  this  problem  in  recent  years, 
and  as  languages  proliferate,  the  need  to  produce  efficient  language 
processors  will  increase.  Development  of  tools  to  build  tools  is  becom- 
ing increasingly  important  and  should  receive  attention  from  software 
vendors. 
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c. 


SOFTWARE  VENDOR  CASE  STUDY  //2  -  SUNDANCE  SYSTEMS 


(SUNDANCE) 


1.  BACKGROUND 

•  Sundance  is  founded  on  the  premise  of  all  small  software  companies  whether 
they  produce  custom  systems  or  packages.  That  premise  is:  a  small  group" of 
highly  skilled  people  can  out-produce  the  average  analyst/programmer  by  at 
least  10:1.  Therefore,  you  can  do  the  job  for  half  as  much  and  still  make  a 
substantial  profit. 

•  Sundance  was  not  founded  with  the  objective  of  concentrating  on  a  particular 
hardware  system.  The  principals  have  a  large  IBM  systems  background. 
However,  their  business  has  tended  to  concentrate  at  the  low  end  of  the  IBM 
line  with  specific  emphasis  on  the  System/38.  They  find  their  concentration 
attractive  because  the  System/38  is  a  good  system  to  use  for  custom  work 
because  of  its  hardware/software  architecture,  and  they  see  it  as  o  system 
with  a  future  (as  do  some  other  respondents  to  this  study).  For  that  reason 
they  are  doing  not  only  custom  work  but  applications  packages  for  the 
System/38. 

2.  EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

•  The  main  productivity  emphasis  is  on  selection  and  retention  of  highly  quali- 
fied personnel  without  much  regard  for  experience  on  a  specific  system. 

•  Their  approach  to  improving  productivity  within  their  organization  is  as 
follows: 

They  have  developed  (or  are  developing)  common  file  definitions, 
skeleton  programs,  and  standard  systems  structures. 
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All  new  employees  are  trained  in  the  concept  and  use  it  regardless  of 
experience. 

The  initial  project  assignments  of  new  personnel  are  made  so  that  they 
must  make  use  of  existing  "building  blocks"  or  skeleton  programs. 

Gradually  they  are  moved  to  more  complex  systems  which  require  that 
attention  be  given  to  use  of  the  standard  structure. 

Eventually  they  are  required  to  develop  skeleton  programs  or  deviate 
from  the  standard  structures. 

It  is  felt  that  their  approach  will  improve  overall  productivity  of  any  indi- 
vidual developing  custom  systems  by  20%  at  present  and  that  this  can  be 
improved  to  30%.  = 

While  this  improvement  may  seem  substantially  less  than  that  of  fourth 
generation  systems,  it  is  not  as  bad  as  it  seems  because  the  improve- 
ment is  being  measured  against  the  entire  development  process  from 
determining  user  requirements  through  installation  of  the  system. 

This  improvement  is  felt  to  give  them  a  competitive  edge  against  other 
vendors  for  custom  systems. 

However,  INPUT  does  not  think  it  will  be  sufficient  for  competitive 
advantage  in  generating  specific  applications  software  packages  suit- 
able for  sale  (see  analysis  of  MSA). 

The  need  is  for  a  means  of  addressing  requirements  definition  and  analysis. 
They  are  counting  on  pseudo  code. 
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3.        TOOLS  AND  TECHNIQUES  EMPLOYED 


•  The  technique  employed  as  described  and  evaluated  above  is  probably  satis- 
factory for  their  current  business  in  most  circumstances.  They  do  not  believe 
in  "canned"  methodologies  but  in  good  system  design  and  construction. 

•  In  their  custom  work,  they  will  purchase  and  install  software  packages  if  this 
is  considered  more  economical  (either  at  customer  request  or  on  their  own 
initiatives). 

4.        ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

•  The  two  principals  in  the  company  are  leveraging  their  own  experience  and 
ability  and  attempting  to  grow  people  of  comparable  capability.  As  long  as 
they  remain  small  this  will  be  successful,  and  organizational  changes  may 
permit  bootstrapping  into  a  larger  organization  using  the  same  approaches. 

•  However,  they  do  not  currently  have  much  of  a  product  line,  and  success  (a 
few  major  custom  contracts)  could  force  rapid  expansion  requiring  new 
productivity  initiatives. 

D.       SOFTWARE  VENDOR  CASE  STUDY  #3  -  SAS  INSTITUTE,  INC.  (SAS) 

I.  BACKGROUND 

•  SAS  has  concentrated  on  statistical  analysis  packages  and  information 
display.  They  have  tremendous  potential  because  of  the  general  need  for  such 
packages  in  both  scientific,  engineering,  and  commercial  applications  systems. 

•  This  concentration  and  a  high  quality  product  made  possible  by  a  small  group 
of  highly  qualified  professional  statisticians  and  systems  programmers  have 
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resulted  in  very  successful  products.  The  excitement  of  producing  a  quality 
product  and  the  potential  for  financial  reward  have  created  a  highly  moti- 
vated work  force  best  described  as  "let's  all  pitch  in  and  work  through  the 
Christmas  holidays."  These  people  have  been  having  fun  while  succeedin-g. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

SAS  is  growing  rapidly  in  order  to  take  advantage  of  an  exceptionally  large 
demand  for  information  management  and  display.  The  excitement  is  still 
there,  but  the  problems  of  growth  are  beginning  to  arise. 

An  unstructured  environment  with  no  rules  as  long  as  the  job  gets  done  can 
appear  to  be  chaos  for  new  employees. 

Someone  who  doesn't  know  what  is  going  on  and  who  to  talk  to  could  very 
easily  get  lost.  The  communication  channels  are  not  defined. 

The  respondent  described  how  he  manages  the  systems  development 
process.  "It  is  all  verbal  communications.  It  is  necessary  to  talk  about 
the  problem  in  order  to  understand  it.  Scattering  written  documents 
around  will  never  get  the  whole  picture  together  so  something  can  be 
done  about  it." 

There  may  be  truth  in  what  he  says  as  long  as  everyone  knows  whom  to 
talk  with,  but  a  new  employee  is  not  going  to  know  that  the  president 
of  the  company  is  the  only  one  who  can  discuss  a  certain  element  of 
design  intelligently  (much  less  have  the  nerve  to  approach  him). 

When  asked  how  he  measured  productivity  among  his  people,  he  stated, 
"(By)  the  seat  of  the  pants.  Ultimately,  it  is  measured  by  whether  or 
not  it  works  and  then  whether  it  is  complete  and  reliable."  (One  has 
the  impression  that  there  are  not  even  schedules;  it  is  primarily  a 
question  of  "getting  it  done  as  soon  as  possible.") 
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When  asked  what  the  company  is  doing  about  productivity  problems  or  poten- 
tial problems,  the  following  views  were  voiced: 

"We  have  fast  response  time  to  problems  internally.  We  don't  have  a 
controller;  therefore,  we  just  do  what  is  necessary.  For  example,  ! 
have  responsibility  and  authority  for  ordering  hardware." 

However,  even  the  respondent  knew  there  were  going  to  be  problems: 
"As  we  grow,  good  people  become  hard  to  find  -  you  can't  have  good 
productivity  without  good  people." 

We  might  add  that  even  good  people  cannot  be  productive  in  an  un- 
structured environment  once  a  certain  critical  mass  is  reached.  It  is 
possible  that  SAS  has  now  reached  that  point. 

SAS  management  needs  to  stand  back  and  recognize  that  they  have  two 
choices: 

They  can  remain  small  and  have  fun  (and  possibly  even  get  rich)  in  an 
environment  where  everybody  knows  everybody  else. 

They  can  decide  they  want  to  grow  even  at  the  expense  of  making  the 
company  less  personal,  and  establish  an  environment  which  is  both 
planned  and  productive.  This  implies  organized  communications, 
product  and  development  planning,  and  control.  (They  might  even  have 
to  hire  a  controller.) 

TOOLS  AND  TECHNIQUES  EMPLOYED 

SAS  product  development  is  split  almost  equally  between  PL/ 1  and 
Assembler.  Some  early  work  was  done  in  FORTRAN,  but  that  represents  less 
than  1%  of  existing  code. 
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The  comments  concerning  Assembly  language  expressed  in  MPG  also  apply  to 
some  degree  at  SAS.  However,  there  are  qualifiers. 

SAS  has  seen  fit  to  take  advantage  of  the  array  processing  capabilities 
of  PL/ 1  rather  than  hand  tailor  everything  using  Assembly  language. 

SAS  products  are  being  interfaced  with  IBM  operating  systems  and  with 
various  data  base  systems  at  a  more  detailed  level  than  RAMIS  is  at 
the  present  time.  This  could  easily  justify  use  of  Assembly  language  to 
assure  performance. 

In  dealing  with  IBM  operating  systems  SAS  must  review  all  IBM  productivity 
improvement  products.  They  use  both  SPF  and  SMP  and  are  even  enthusiastic 
about  SPF.  However,  they  feel  ISPF  is  regressing  toward  usual  IBM  quality. 

Generally  speaking,  the  attitude  is  that  most  tools  and  methodologies  are  for 
people  who  don't  know  what  they  are  doing.  This  obviously  does  not  apply  to 
them. 

ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

SAS  products  address  areas  where  applications  programmers  and  end  users 
have  substantial  requirements  and  limited  expertise.  Their  products  have 
been  of  sufficient  quality  that  most  companies  cannot  justify  developing 
comparable  capability  much  less  provide  comparable  capabilities  in  each 
applications  system.  (IBM  was  an  early  customer  in  their  internal  business 
planning  function.) 

As  far  as  SAS's  internal  product  development  is  concerned,  it  is  our  impression 
that  they  have  reached  the  end  of  the  line  with  their  current  management 
style  and  development  environment.  (This  is  sad.  Just  being  around  the  place 
gets  the  adrenalin  flowing  and  takes  one  back  to  the  "good  old  days"  of  20 
years  ago.) 
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They  are  probably  going  to  have  either  a  major  product  slippage  which 
will  attract  attention  from  both  the  sales  force  and  corporate  manage- 
ment or  the  burden  of  maintenance  will  become  unbearable  as  the 
original  developer  becomes  a  company  vice  president  or  leaves  the 
company. 

•  Company  management  will  be  faced  with  a  serious  challenge,  and  their  ability 
to  respond  v/ill  determine  their  future  growth  and  success.  Properly  handled, 
a  productive  and  creative  environment  can  be  maintained  even  in  a  large 
company.  MSA  seems  to  have  achieved  growth  through  successful  environ- 
mental change  (although  they  had  problems  in  their  early  history  also). 


E.       SOFTWARE  VENDOR  CASE  STUDY  #4  -  MANAGEMENT  SCIENCE 
AMERICA,  INC,  (MSA) 


BACKGROUND 


•  Next  year  will  be  MSA's  twentieth  year  as  a  company  specializing  in  packaged 
software.  They  have  been  successful  and  have  maintained  their  direction  and 
product  focus  so  that  they  are  the  largest  computer  services  company  special- 
izing exclusively  in  software  packages.  They  have  grown  to  $100  million  in 
sales  (projected  for  1982)  and  to  over  1,000  employees  and  have  managed  to 
maintain  a  productive  environment  for  their  systems  employees. 

•  President  John  Imlay  becomes  personally  involved  in  most  decisions  which 
affect  the  employees'  working  environment,  and  he  has  remained  accessible  to 
employees  at  all  levels.  A  major  objective  is  to  be  sure  that  all  employees 
have  a  personal  interest  in  the  success  not  only  of  the  company  but  of  the 
products  or  services  they  are  associated  with. 
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The  attitude  of  management  is  very  positive;  they  believe  they  have  finally 
learned  how  to  manage  the  development  of  software  products.  They  admit 
they  had  problems  in  the  1960s  which  motivated  them  to  address  the  manage- 
ment issues  involved. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

The  Group  Vice  President  of  Development  presented  their  management  phil- 
osophy, which  he  considers  to  be  the  most  important  contribu-ting  factor  to 
productivity  at  MSA.  It  emphasizes  the  following: 

Careful  selection  of  personnel. 

Continuing  training  at  all  levels. 

Clearly  established  lines  of  authority. 

Management  by  objectives  (goals). 

Incentives  of  up  to  50%  based  on  project  performance. 

Project  planning. 

Business  plans. 

Technical  plans. 

"Hell  week"  which  establishes  priorities  and  eliminates  redun- 
dancy. 

Emphasis  on  communications  at  all  levels  (review  meetings  conducted 
each  week). 
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Points  made  about  personnel  managennent  were  as  follows: 

Twelve  percent  turnover  (this  is  the  exact  percent  of  turnover  con- 
sidered favorable  by  SCE). 

Group  interviews  when  selecting  employees. 

Management  goes  to  the  field  for  an  understanding  of  sales  and  clTent 
problems. 

Bonuses  are  awarded  twice  a  year  at  the  manager's  discretion.  They 
may  be  awarded  to  either  people  or  projects  (bonuses  are  in  addition  to 
incentive  objectives  established  for  projects). 

Complete  terminal  support  for  on-line  development  and  maintenance. 

Individual  offices  for  all  professionals  in  an  atractive  physical  environ- 
ment. (They  consider  these  important  and  have  noticed  that  most  nevy 
employees  make  a  point  of  bringing  their  family  or  friends  into  the 
office  soon  after  they  are  employed.) 

Managers  and  project  leaders  are  given  the  authority  to  look  for  the  tools  and 
aids  they  need  to  get  their  job  done.  For  this  reason,  there  has  been  only 
informal  discussion  about  which  are  good  and  bad.  There  are  no  formal  evalu- 
ation procedures  at  present,  and  this  is  an  obvious  need  for  the  company. 

TOOLS  AND  TECHNIQUES  EMPLOYED 

COBOL  is  the  primary  language  for  implementation,  and  both  TSO  and  CMS 
are  used  because  experience  in  IBM  operating  environments  is  a  must  for 
practically  all  MSA  products. 
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Since  project  leaders  may  employ  tools  and  techniques  to  get  their  jobs  done, 
a  variety  of  tools  and  techniques  are  employed.  For  example,  payroll  develop- 
ment is  using  Yourdon  Methodology  and,  since  this  is  one  of  their  biggest 
development  efforts,  others  are  beginning  to  look  at  it.  At  present,  there  is 
also  a  review  committee  to  make  a  selection  of  a  data  dictionary/directions 
system. 

There  is  currently  an  internal  effort  underway  to  standardize  an  "information 
management"  portion  of  their  products.  Specifically,  standard  modules  will 
assure: 

Consistency  of  input  across  systems. 

Detailed  data  transfer  conventions  and  reporting  cycle  coordinations. 

Standardized  retrieval  and  consolidation  procedures. 

They  also  hope  to  make  these  modules  multilingual  in  their  report 
preparation  phase. 

There  are  objectives  for  implementation  during  1982-1983  with  a  goal 
of  producing  only  20%  new  code  on  projects  after  1984. 

The  tools  to  manage  data  and  interface  with  systems  software  are  pro- 
grammed in  COBOL  (30%  to  35%)  and  Assembler  (65%  to  70%).  The  informa- 
tion Manager  also  uses  some  RAM  IS  and  Easytrieve. 

ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

The  scope  of  the  research  did  not  permit  multilevel  interviews  such  as  those 
conducted  in  the  productivity  study,  but  the  management  philosophy  seems 
sound. 
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•  A  group  interview  with  three  managers  reporting  to  the  Group  Vice  President 
revealed  that  the  management  philosophy  is  generally  well  received.  How- 
ever, one  manager  stated,  "Sometimes  the  incentive  system  gets  out  of 
phase.  I  am  deferring  income  by  coming  in  late  on  a  project  with  the  hope  I 
can  make  it  up  for  my  people  on  the  maintenance  phase."  It  seems  to  us  that 
even  being  made  to  think  of  such  trade-offs  is  a  big  step  in  the  right  direction. 

•  It  appears  that  MSA  has  passed  the  critical  mass  test  for  software  develop- 
ment with  flying  colors.  We  were  favorably  impressed  except  for  the  some- 
what lax  attitude  about  tool  and  methodology  evaluations. 

F,       SOFTWARE  VENDOR  CASE  STUDY  #5  -  INTEL,  COMMERCIAL  SYSTEMS 
DIVISION  (INTEL) 

I.  BACKGROUND 

•  Background  of  the  approach  taken  by  Intel  goes  back  to  a  study  done  by 
INPUT  in  1977.  The  purpose  and  results  of  that  study  were  as  follows: 

Actually  there  were  two  studies,  one  concerned  with  the  market  for  a 
back-end  data  base  computer  and  the  other  with  the  market  for  a 
small,  standalone  data  base  computer. 

Intel  eventually  took  two  actions: 

They  acquired  MSI  and  the  System  2000  data  base  management 
system  in  order  to  obtain  the  necessary  software  systems  re- 
sources to  enter  the  data  base  computer  market. 

They  decided  to  develop  a  microprocessor-based,  relational  data 
base  machine  that  functions  as  an  intelligent  mass  storage 
controller  for  one  or  more  host  computers.  The  first  Intel  data 
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base  processor  has  been  designated  the  iDBP  86/440  and  first 
customer  shipments  are  just  beginning  to  take  place. 

It  was  decided  to  interview  Dr.  Eugene  Lowenthal,  technical  director  of  MSI 
prior  to  its  acquistion  by  Intel,  who  was  responsible  for  the  development  of 
the  iDBP  86/440.  Dr.  Lowenthal  now  serves  as  the  Director  of  Business  and 
Market  Planning  reporting  to  the  Group  Vice  President  of  the  Systems 
Group.  This  was  decided  for  the  following  reasons: 

To  obtain  some  insight  into  the  future  of  relational  data  base  systems 
as  a  productivity  improvement  approach. 

To  determine  the  development  problems  of  implementing  DBMS  func- 
tions in  microprocessors. 

To  assess  the  impact  of  such  systems  in  an  office  environment  and  on 
host  processing. 

The  interview  with  Dr.  Lowenthal  did  not  follow  the  interview  guide  closely, 
but  it  revealed  the  profound  thinking  of  one  who  has  addressed  systems 
development  of  DBMS  on  both  a  hardware  and  a  software  basis.  The  case 
study  presents  Dr.  Lowenthal's  opinions  unless  otherwise  specified. 

EVALUATION  OF  CURRENT  SITUATION  AND  NEEDS 

The  handling  of  data  and  information  is  at  the  heart  of  the  development 
problems  of  commercial  applications.  DBMS  is  a  means  of  solving  these 
problems. 

IBM  is  "somewhat  stuck  with  its  hardware  architecture  and  a  variety  of 
conventional  data  models  on  mainframes  (IMS,  System  2000,  and  the  Cullinane 
clones)." 


-  212  - 


IBM  is  trapped  because  of  the  large  hardware/software  systems  performance 
problems,  but  there  is  a  big  push  for  relational  in  the  "mini/micro"  world 
because  they  can  start  fresh. 

"There  is  no  intrinsic  reason  relational  systems  are  less  efficient,  and  there  is 
a  major  business  opportunity  for  relational  systems  on  IBM  mainframes." 

Relational  demonstrates  a  5:1  advantage  in  lines  of  code  and  probably  a  TO: I 
productivity  advantage  if  things  are  "actually  measured."  In  addition  mainte- 
nance and  documentation  are  easier. 

Data  base  people  should  concentrate  on  data  base  problems  (data  structuring, 
storage,  performance,  etc.)  and  forget  about  human  factors  (user  friendly 
systems).  Leave  those  problems  to  psychologists  and  artificial  intelligence 
people.  Concentrate  on  the  primary  problems,  and  the  tools  to  obtain  access 
will  appear. 

There  are  "hidden  data  bases"  among  non-DP  users.  It  would  be  advisable  for 
DBMS  developers  to  let  the  office  automation  and  CAD  people  worry  about 
those.  DBMS  developers  have  their  hands  full  with  their  own  problems  with- 
out trying  to  solve  everything. 

INPUT'S  feeling  about  the  iDBP  86/440  (documentation  available)  is  that  it 
may  suffer  because  of  Dr.  Lowenthal's  thinking.  Specifically: 

The  iDBP  86/440  is  a  data  base  machine  (engine)  which  must  be  inte- 
grated before  it  has  any  use,  and  Intel  is  now  attempting  to  sell  it  in 
the  end  user  market.  There  are  two  essential  tasks  to  complete  before 
the  engine  can  be  integrated: 

Implementation  of  a  communications  drive. 
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Development  of  a  host-based,  end  user  "personality"  through 
which  the  data  base  facilities  are  exploited. 

The  iDBP  86/440  has  been  termed  "faceless"  by  some  industry 
analysts.  It  has  left  the  user  interface  up  to  the  systems  integrator, 
who  in  turn  will  be  responsible  for  selling  to  end  users.  This  strategy 
reflects  not  only  the  thinking  of  Dr.  Lowenthal  but  also  Intel's  tradi- 
tional business  strategy  of  producing  cheap,  high  performance  com- 
ponents that  others  integrate  into  systems.  Whether  or  not  this 
strategy  will  be  viable  as  intelligence  is  incorporated  into  the  hardware 
remains  to  be  seen.  But  one  thing  is  definite:  the  migration  of  soft- 
ware to  hardware/firmware  is  a  trend  which  will  continue. 

The  implementation  methods  of  software  for  micro  systems  were  character- 
ized by  Lowenthal  as  at  least  a  generation  behind  those  of  larger  systems. 
Recognition  that  this  is  the  case  and  that  applications  developers  must  inter- 
face to  micros  is  of  concern  to  Intel,  which  is  now  working  on  the  "software 
lab  of  the  future." 

TOOLS  AND  TECHNIQUES  EMPLOYED 

The  iDBP  86/440  was  developed  using  PLM,  but  that  presented  a  lot  of  prob- 
lems. ADA  and  other  languages  are  being  considered  for  future  development. 

In  addition,  Lowenthal  forecast  a  "super  UNIX  (operating  system)  without  the 
unfriendly  things"  for  microprocessors  which  would  facilitate  software  devel- 
opment and  integration  with  hosts. 

ASSESSMENT  OF  PRODUCTIVITY  INITIATIVES 

Intel  has  selected  what  it  considers  to  be  a  major  stumbling  block  to  produc- 
tivity improvement  -  poor  performance  characteristics  of  the  relational  data 
model  on  large-scale  IBM  hardware/software  systems  -  and  has  decided  to 
provide  a  means  (iDBP)  of  bypassing  the  problem  in  two  environments: 
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The  first  is  the  distributed  processing  (office  automation)  environment 
where  it  can  be  used  in  either  a  local  area  network  or  as  an  intelligent 
cluster  controller  with  the  capability  of  providing  a  shared  relational 
data  base  among  workstations. 

The  second  is  as  a  DBMS  backend  to  a  host  where  it  can  relieve  the 
host  of  DBMS  file  management  burden  (and  provide  relationci  capa- 
bility). 

Thus,  the  iDBP  provides  for  both  the  geographic  and  architectural 
distribution  of  processing. 

•  Such  a  processor  is  needed,  and  Intel  indicates  the  iDBP  86/440  is  only  the 
first  of  the  product  line.  The  primary  question  is  whether  the  integration 
should  be  left  open.  In  other  words,  why  not  give  the  product  the  logical  IBM 
MVS  "personality"  which  would  make  it  immediately  available  to  end  users? 
Perhaps  the  answer  is  that  IBM  is  expected  to  be  the  biggest  customer. 


-  215  - 


INPUT 


i 


-  216  - 


APPENDIX    A:   LIST    OF   COMPANIES  INTERVIEWED 


APPENDIX  A: 


LIST  OF  COMPANIES  INTERVIEWED 


A.  EDP  USER  DEPARTMENTS 

•  Southern  California  Edison 

•  The  Singer  Company 

•  The  Continental  Insurance  Company 

•  McGraw-Hill,  Inc. 

•  The  Citizens  and  Southern  Bank 

•  University  of  North  Carolina 

•  Norfolk  Southern  Railway 

B.  SOFTWARE  VENDORS 

•  The  Mathematica  Products  Group 

•  SAS  Institute,  Inc. 
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Industry 
Public  Utility 
Manufacturing/Retailing 
Insurance 
Publishing 
Banking 
Education 
Transportation 

Activity 
Systems  Software 
Statistical  and  Graphics  Software 

INPUT 


Management  Science  America  Applications  Software 

Sundance  Systems  Custom  Consulting/Systems 

Development 

Intel  Systems  Corporation 
(Systems  Group)  Data  Base  Management  System 
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APPENDIX   B:  QUESTIONNAIRE 


I 


CATALOG  NO. 


INTERVIEW  GUIDE 
CDL  -  PRODUCTIVITY 


(No  tabulation.  Interviewer  will  do  all 
data  structuring  and  analysis.) 


Respondent  Characteristics 
1.  Industry:   


Revenues : 


Organization  and  Size: 
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CATALOG  NO. 


2.    a)     Is  there  general  concern  about  productivity?  (Rank  concerns.) 


b)    What  steps  have  been  taken? 


c)     Is  there  any  formal  organization(s)  concerned  with  corporate 
productivity?    if  so,  describe: 
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a)    Describe  the  EDP  organization  (including  staffing)  : 


b)    Wiiere  do  you  fit  in  the  organization? 


What  are  the  approximate  personnel  and  EDP  budgets  for  the  organlza- 
tion(s)  described  above? 
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CATALOG  NO. 


5.    Where  does  responsibility  for  the  following  functions  reside? 
a)    Systems  Programming:   


b)    Applications  Development: 


c)    Applications  Maintenance: 


d)    Mainframe  and  Storage  Systems  Selection  (Hosts)  : 


e)    Distributed  Computers  and  Storage  (Selection)  : 


f)     Terminals  (Selection) : 
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CATALOG  NO. 


J 


g)    Communications  Systems  (Hardware,  Software) 
-  Data: 


-    Voice  (include  Conferencing): 


-  Message: 


h)    Personal  Computers  (Hardware  and  Software): 


i)     Office  Automation  Equipment  (Selection) 
-    Word  Processing  Equipment:   


-    Office  Copiers: 


-    Filing  Systems: 


-  Micrographics: 


Library  Systems: 
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How  are  contracts  for  outside  computer /communications  services  iiandled? 
(Processing,  Storage,  Data  Bases,  Software,  Personnel,  Systems  Develop 
ment.  Consulting)  : 
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Software  Development  Characteristics 

7.    Describe  the  responsibility  of  the  EDP  Department  for  the  following: 

■  • 

a)    Number  of  Systems  (include  definition)  :   


b)    Number  of  Programs  (include  definition)  : 


c)    Lines  of  Code  (include  definition) : 


Developed : 
(per  year) 

Maintained : 


8.    a)     Describe  the  Hardware/Software  Systems  Organization  (Hosts, 
Distributed  Processors,  Communication,  Facilities,  Personal 
Computers,  Office  Systems,  etc.)  for  which  systems  are  developed 
and  maintained: 


-  225  - 


INPUT 


CATALOG  NO. I  I  I  I  I  I  I 


b)    Describe  the  development/maintenance  system  (facilities)  whicli  are 
employed.     (Including  Hardware  System  Identification,  Interactive 
Facility  -  TSO,  CMS,  USPC,  VSE/ICCF,  etc.): 


c)    Explain  the  background  of  the  development  maintenance  system 
which  is  currently  being  used.  (What  gave  impetus  to  it?    Did  it 
evolve  or  was  it  planned?    How  long  installed?    Measurable  results?) 


Please  rate  the  current  system  on  the  following  attributes  (1=  Out- 
standing, 2  =  Good,  3  =  Fair,  4  =  Poor)  : 


Reliability 


Documentation 


Efficiency 


User  Instruction/Training 


Ease  of  Installation 


Maintenance  by  Vendors 


Ease  of  Use 


Overall  Satisfaction 


Trouble  Shooting 
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9.    For  the  systems  being  developed  and  maintained,  what  percentage 
fall  into  the  following  cagegories? 


Target  Hardware  Systems 

Target  Software  Systems 


Systems  Software 


10.    What  development  languages  are  being  used  and  approximate  percentage 
of  systems  being  developed?    (COBOL,  FORTRAN,  PL/1,  RPG,  Basic 
PASCAL,  APL,  DMS,  ADF,  SPL,  Assembler,  etc.): 


11.  What  languages  are  used  in  maintaining  systems  (and  approximate 
percentages) ? 
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Describe  the  development  environment  and  facilities: 
a)     Information  Center?    How  organized?   


b)    Interactive  facilities  for  development  and  maintenance: 

Number  of  Terminals:  ;  

Location:   " 

Software: 


c)    Are  there  development  activities  (or  their  equivalent)  outside  the 
EDP  department? 


Are  EDP  personnel  assigned  to  end  user  organizations  for  direction 
(project  selection  and  priorities)?    How  are  they  budgeted? 
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Do  end  users  do  their  own  development?    How  is  it  budgeted? 


d)    How  are  project  priorities  established? 


e)    How  are  "make  versus  buy"  decisions  made? 
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Software  Development  Productivity 


13.     How  do  you  feel  generally  about  productivity  in  tiie  EDP  systems  area? 


14.    What  are  the  primary  problems  and  bottlenecks?    Can  you  rank  them 
in  order  of  importance? 


15.    a)  How  do  you  scope  the  problem?    (Management  dissatisfaction,  back- 
log, missed  schedules,  quality,  etc.): 


b)  How  do  you  manage  the  development  process?    (metrics  used)  : 


16.     How  do  you  measure  productivity?  (Subjective,  meeting  schedules, 
lines  of  code,  etc.)  : 


-  230  - 


CATALOG  NO. 


17.    How  serious  is  the  problem? 

a)  in  the  industry?   

b)  In  your  company?   

c)  What  is  going  to  happen  if  things  don't  improve? 


18.    Where  is  the  problem  centered? 

a)  In  the  systems  life  cycle  (rank): 

  Problem  Definition 

  Analysis 

  Design 

  Programming 

  Testing  and  Shakedown  (Quality  Control) 

Maintenance  and  Enhancement 


b)  In  the  structure  of  the  problem  (rank)  : 

  Broad-based  Management 

  User  Involvement 

  Effective  Personnel 

  Commitment  to  Quality 

Tools  and  Aids 
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What  are  you  currently  doing  about  the  problem? 
a)  Measurement  and  Evaluation:   


b)  Personnel  (retention,  training,  etc.): 


c)  User  Involvement: 


d)  Broad-based  Management: 


e)  Tools  and  Aids: 


f)   Systems  Approaches   (hardware,  software)  : 


g)  Alternatives  to  Systems  Implementation: 


h)  Quality  Evaluation  (Assurance  ) : 


i)    Life  Cycle  Emphasis: 


j)   Environmental  (including  hardware,  software,  service  and  facilities) 


k)  Other: 
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20.    a)  Have  you  investigated  and /or  adopted  any  methodology  or  tools 

associated  with  the  following  (and  when)  : 

investigated  Adopted 

    Requirements  Analysis/Definition 

    Systems  Design 

    Programming 

    Testing/Debugging 

    System  Construction 

    System  Maintenance 

    Operation  and  Management  of  Development 

System 

    Packaged  Programs  - 

    Source  Code  Management 

    Source  Code  Reuse 

    Automatic  Programming 

    Project  Management 

    Data  Dictionary /Directory 

    Prototyping 

b)  What  were  the  reasons  you  failed  to  adopt  any  investigated  and  not 
installed? 


c)  Give  evaluation  of  those  installed: 
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d)  Are  you  familiar  with  the  following  methodologies  and /or  tools? 

No  Knowledge  Know  About  Have  Used 

Pseudo  Code       

Jackson  Methodology    -     

SADT       

HlPO      _^  

Nassi-Scheiderman  Charts 


21.    Which  ones  do  you  consider  to  be  the  most  promising?  (Include  alternatives.) 


! 

22.    What  would  be  of  the  most  benefit  to  you  in  pursuing  productivity 

improvement?    (Implies  things  which  are  somewhat  beyond  his  control.) 


23.    How  effective  do  you  feel  you  have  been  in  improving  productivity? 
Can  you  quantify  it  over  any  period  of  time? 


24.    What  do  you  anticipate  you  may  be  able  to  accomplish  in  the  future? 
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25.    What  are  the  most  promising  things  you  see  occuring  in  the  DP 
Industry  which  are  affecting  productivity? 


26.    What  are  the  most  pressing  challenges  you  anticipate  in  the  1980's 
(Communications,  Systems  Development,  Personnel,  Office  Auto- 
mation, etc.)?    Rank  your  challenges  in  terms  of  severity. 
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IBM's  Productivity  Support  and  Strategy 


27.    a)  Are  you  familiar  with  BSP  and  BiCS? 


b)  What  is  your  evaluation  of  them? 


28.     Do  you  use  IBM  provided  packaged  programs? 
if  so,  please  provide  list:   


29.     a)   Do  you  use  any  IBM-provided  productivity  products?  If  so,  please 
rate  (1-4) : 


IIS    DMS 

STAIRS  SQL/DS 


APL    SPF 

PLANCODE    System  IPO 

CIS    SMP 

ADF 


b)  Comments  concerning  use; 
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30.    What  do  you  think  IBM's  strategy  is  as  far  as  the  following  are 
concerned  ? 

a)  Encouragement  of  independent  software  houses  to  develop  applica- 
tions packages? 


b)  Are  you  familiar  with  the  ASDC?    If  so,  what  was  your  reaction? 


c)  What  do  you  consider  the  advantages  and  disadvantages  of  pre- 
configured  and  prepackaged  systems  such  as  the  4321,  4331-11 
and  SSX/VSE?    Do  you  see  this  as  a  trend  which  may  be  employed 
on  other  systems  (large  and  small)  and  what  is  your  reaction? 


d)  IBM  services  from  the  Information  Services  Network  seem  to  be 
concentrated  on  productivity  tools  (MVSPS  and  VMPS) .    What  are 
your  thoughts  about  this  announcement  and  it's  impact  on  the 
productivity  problem?    Will  it  help  you  or  others? 
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e)  What  do  you  think  IBM's  strategy  is  for  the  network? 


f)   Under  its  reorganization,  IBM  has  split  responsibility  for  software 
development  across  many  organizations.     (Explain)    What  do  you 
think  the  significance  of  this  is? 


g)  Specifically,  what  do  you  think  IBM's  software  strategy  is  for 
small  scale  systems? 
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h)  How  do  you  feel  the  split  in  software  responsibility  will  affect 
such  broad  strategies  as: 

-  SNA  Strategy:  


-    Office  Automation: 


-    Computer/Communications  Services: 


-    Consumer  Products  and  Services: 
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Summary  and  Conclusions 


31.    How  would  you  summarize  your  conclusions  concerning: 
a)  The  "Productivity  Problem":   


b)  The  current  state  of  the  art  in  tools  and  aids,  and  their  future: 


c)  The  future  direction  of  systems  development  management  and 
implementation : 


d)  The  major  problems  confronting  development  managers: 


e)  The  major  opportunities  available  in  solving  these  problems: 
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